diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2013-11-11 10:43:00 -0500 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2013-11-11 10:43:00 -0500 |
commit | 04e6ee40206fa61dc856bf2840ce6bb198d5200c (patch) | |
tree | 1b02114159fbb2e889fbaa370dc13d118d159ae4 /src/backend/parser/parse_relation.c | |
parent | 8e41c621a625f154e96f40ce688a036520cb59aa (diff) | |
download | postgresql-04e6ee40206fa61dc856bf2840ce6bb198d5200c.tar.gz postgresql-04e6ee40206fa61dc856bf2840ce6bb198d5200c.zip |
Re-allow duplicate aliases within aliased JOINs.
Although the SQL spec forbids duplicate table aliases, historically
we've allowed queries like
SELECT ... FROM tab1 x CROSS JOIN (tab2 x CROSS JOIN tab3 y) z
on the grounds that the aliased join (z) hides the aliases within it,
therefore there is no conflict between the two RTEs named "x". The
LATERAL patch broke this, on the misguided basis that "x" could be
ambiguous if tab3 were a LATERAL subquery. To avoid breaking existing
queries, it's better to allow this situation and complain only if
tab3 actually does contain an ambiguous reference. We need only remove
the check that was throwing an error, because the column lookup code
is already prepared to handle ambiguous references. Per bug #8444.
Diffstat (limited to 'src/backend/parser/parse_relation.c')
-rw-r--r-- | src/backend/parser/parse_relation.c | 15 |
1 files changed, 13 insertions, 2 deletions
diff --git a/src/backend/parser/parse_relation.c b/src/backend/parser/parse_relation.c index 42de89f5101..d473749e303 100644 --- a/src/backend/parser/parse_relation.c +++ b/src/backend/parser/parse_relation.c @@ -131,6 +131,18 @@ refnameRangeTblEntry(ParseState *pstate, * Search the query's table namespace for an RTE matching the * given unqualified refname. Return the RTE if a unique match, or NULL * if no match. Raise error if multiple matches. + * + * Note: it might seem that we shouldn't have to worry about the possibility + * of multiple matches; after all, the SQL standard disallows duplicate table + * aliases within a given SELECT level. Historically, however, Postgres has + * been laxer than that. For example, we allow + * SELECT ... FROM tab1 x CROSS JOIN (tab2 x CROSS JOIN tab3 y) z + * on the grounds that the aliased join (z) hides the aliases within it, + * therefore there is no conflict between the two RTEs named "x". However, + * if tab3 is a LATERAL subquery, then from within the subquery both "x"es + * are visible. Rather than rejecting queries that used to work, we allow + * this situation, and complain only if there's actually an ambiguous + * reference to "x". */ static RangeTblEntry * scanNameSpaceForRefname(ParseState *pstate, const char *refname, int location) @@ -175,8 +187,7 @@ scanNameSpaceForRefname(ParseState *pstate, const char *refname, int location) /* * Search the query's table namespace for a relation RTE matching the * given relation OID. Return the RTE if a unique match, or NULL - * if no match. Raise error if multiple matches (which shouldn't - * happen if the namespace was checked correctly when it was created). + * if no match. Raise error if multiple matches. * * See the comments for refnameRangeTblEntry to understand why this * acts the way it does. |