From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: WIP patch for LATERAL subqueries |
Date: | 2012-08-06 02:07:16 |
Message-ID: | 3819.1344218836@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> On 08/05/2012 05:58 PM, Tom Lane wrote:
>> Currently the patch only implements the syntax called out in the standard,
>> namely that you can put LATERAL in front of a <derived table>, which is
>> to say a parenthesized sub-SELECT in FROM. It strikes me that it might be
>> worth allowing LATERAL with a function-in-FROM as well.
> Pro. As you say this is the main use case, and the longer syntax just
> seems unnecessary fluff.
After some experimentation it seems that this only works if we promote
LATERAL to a fully reserved keyword. Apparently the reason is that
given non-reserved LATERAL followed by an identifier, it's not clear
without additional lookahead whether we have "LATERAL func_name ..."
or the LATERAL is a table name and the identifier is an alias. And the
parser has to make a shift/reduce decision before it can look beyond the
identifier. (Without the LATERAL func_name syntax, there's no ambiguity
because LATERAL in its keyword meaning must be immediately followed by a
left paren.)
Since LATERAL has been a reserved word in every SQL spec since SQL:99,
I don't feel too bad about making it fully reserved for us too, but
nonetheless this is a cost of adding this syntax.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Etsuro Fujita | 2012-08-06 02:41:48 | Re: WIP Patch: Use sortedness of CSV foreign tables for query planning |
Previous Message | Tom Lane | 2012-08-05 23:52:56 | Re: WIP patch for LATERAL subqueries |