Re: BUG #15904: ERROR: argument of LIMIT must not contain variables

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Lakradi Marwan <lakradimarwan(at)gmail(dot)com>
Cc: PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #15904: ERROR: argument of LIMIT must not contain variables
Date: 2019-07-11 16:45:42
Message-ID: CAKFQuwZXPCO22LE0G6QGrnzsMaUb6Byem62dxq+ASKBvGqZGew@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thu, Jul 11, 2019 at 9:26 AM Lakradi Marwan <lakradimarwan(at)gmail(dot)com>
wrote:

> Thank you for your quick feedback,
>
> In my opinion, your query should return :
> Id, Text
> 1| 1, 'one'
>
> and be interpreted as due to variable type :
> LIMIT CASE WHEN 1 = 1 THEN 1 ELSE 2 END;
>
> Am I wrong in the way I see the situation ?
>
> I think that in the case of a variable, the data should be retrieved until
> the condition is reached. Like LIMIT_TILL {condition}
>

That's not an unreasonable expectation. But that isn't how LIMIT is
defined. LIMIT provides a query result max record count to return to the
client - mostly to facilitate pagination when used in concert with ORDER BY
(for determinism) and OFFSET (to skip already seen records). That max is a
constant determined at plan time which means it cannot rely upon any of the
data the query itself may generate.

SQL is set oriented and your expectation is incompatible with that
fundamental property of the system. If you don't want records "after"
something you need to apply a inequality filter in the WHERE clause to
remove the undesired records.

David J.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andrew Gierth 2019-07-11 17:26:52 Re: The result of the pattern matching is incorrect when the pattern string is bpchar type
Previous Message Lakradi Marwan 2019-07-11 16:26:41 Re: BUG #15904: ERROR: argument of LIMIT must not contain variables