2012/8/6 Tom Lane <t...@sss.pgh.pa.us>: > Andrew Dunstan <and...@dunslane.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.
+1 Pavel > > regards, tom lane > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
