Re: IN question

On Wed, 2008-12-10 at 16:11 -0800, Neil Conway wrote:
> On Wed, Dec 10, 2008 at 3:39 PM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> > And if it's additional memory, it should probably be a different GUC.
>
> Measuring the limit in bytes makes no sense, anyway.
>

Sure it does. If you're concerned about the application generating
infinite SQL strings and sending them to the server, a byte limit on the
SQL string would solve it.

After all, as Josh pointed out, there _is_ a limit measured in bytes:
available memory (and some operating systems don't handle that very
well).

Maybe we shouldn't add such a limit, but it at least makes sense.

> > If there is an explicit limit, which sounds reasonable, I think it's
> > good to separate parsing limits from executor limits.
>
> IMHO this would not be very useful: should we also reject queries with
> more than k WHERE clauses, FROM elements, or string literals longer
> than k bytes? I think the time would be better spent working on
> developing proper support for resource limits / quotas.
>

I'm not suggesting we introduce a bunch of additional limits. I'm just
saying that if we introduce a scanner/parser limit (I'm not arguing
either way), I think it should be a separate GUC from work_mem.

I think you're right that this falls under the heading of resource
limits and quotas, and whatever we do should fit within some kind of
overall model.

Regards,
Jeff Davis