aboutsummaryrefslogtreecommitdiff
path: root/src/interfaces/ecpg/ecpglib/misc.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2013-01-26 16:18:42 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2013-01-26 16:18:42 -0500
commit2378d79ab29865f59245744beb8f04a3ce56d2ae (patch)
tree58b1624c0041c7ae85394b8d3b559f50b7ac6191 /src/interfaces/ecpg/ecpglib/misc.c
parent8865fe0ad3e4260db0e67e2064200d96c0999fa0 (diff)
downloadpostgresql-2378d79ab29865f59245744beb8f04a3ce56d2ae.tar.gz
postgresql-2378d79ab29865f59245744beb8f04a3ce56d2ae.zip
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.
Diffstat (limited to 'src/interfaces/ecpg/ecpglib/misc.c')
0 files changed, 0 insertions, 0 deletions