diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2013-01-26 16:18:42 -0500 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2013-01-26 16:18:42 -0500 |
commit | 2378d79ab29865f59245744beb8f04a3ce56d2ae (patch) | |
tree | 58b1624c0041c7ae85394b8d3b559f50b7ac6191 /src/interfaces/ecpg/ecpglib/misc.c | |
parent | 8865fe0ad3e4260db0e67e2064200d96c0999fa0 (diff) | |
download | postgresql-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