Re: WIP patch for LATERAL subqueries - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: WIP patch for LATERAL subqueries
Date
Msg-id CAFj8pRBE5SzVTdNSw9EO+GiMT3JyZAAygK4yzZpL-kuufPnuJw@mail.gmail.com
Whole thread Raw
In response to Re: WIP patch for LATERAL subqueries  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
2012/8/6 Tom Lane <tgl@sss.pgh.pa.us>:
> Andrew Dunstan <andrew@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


pgsql-hackers by date:

Previous
From: "Etsuro Fujita"
Date:
Subject: Re: WIP Patch: Use sortedness of CSV foreign tables for query planning
Next
From: Amit Kapila
Date:
Subject: Re: [WIP] Performance Improvement by reducing WAL for Update Operation