Re: WIP patch for LATERAL subqueries
От | Tom Lane |
---|---|
Тема | Re: WIP patch for LATERAL subqueries |
Дата | |
Msg-id | 3819.1344218836@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: WIP patch for LATERAL subqueries (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: WIP patch for LATERAL subqueries
|
Список | pgsql-hackers |
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. regards, tom lane
В списке pgsql-hackers по дате отправления: