Make LATERAL implicit for functions in FROM.
The SQL standard does not have general functions-in-FROM, but it does allow UNNEST() there (see the <collection derived table> production), and the semantics of that are defined to include lateral references. So spec compliance requires allowing lateral references within UNNEST() even without an explicit LATERAL keyword. Rather than making UNNEST() a special case, it seems best to extend this flexibility to any function-in-FROM. We'll still allow LATERAL to be written explicitly for clarity's sake, but it's now a noise word in this context. In theory this change could result in a change in behavior of existing queries, by allowing what had been an outer reference in a function-in-FROM to be captured by an earlier FROM-item at the same level. However, all pre-9.3 PG releases have a bug that causes them to match variable references to earlier FROM-items in preference to outer references (and then throw an error). So no previously-working query could contain the type of ambiguity that would risk a change of behavior. Per a suggestion from Andrew Gierth, though I didn't use his patch.
Showing
- doc/src/sgml/queries.sgml 16 additions, 4 deletionsdoc/src/sgml/queries.sgml
- doc/src/sgml/ref/select.sgml 28 additions, 13 deletionsdoc/src/sgml/ref/select.sgml
- src/backend/parser/parse_clause.c 16 additions, 5 deletionssrc/backend/parser/parse_clause.c
- src/test/regress/expected/join.out 24 additions, 13 deletionssrc/test/regress/expected/join.out
- src/test/regress/expected/rangefuncs.out 8 additions, 5 deletionssrc/test/regress/expected/rangefuncs.out
- src/test/regress/sql/join.sql 8 additions, 5 deletionssrc/test/regress/sql/join.sql
- src/test/regress/sql/rangefuncs.sql 1 addition, 1 deletionsrc/test/regress/sql/rangefuncs.sql
Loading
Please register or sign in to comment