From 04e6ee40206fa61dc856bf2840ce6bb198d5200c Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Mon, 11 Nov 2013 10:43:00 -0500 Subject: 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. --- src/backend/parser/parse_clause.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'src/backend/parser/parse_clause.c') diff --git a/src/backend/parser/parse_clause.c b/src/backend/parser/parse_clause.c index 64c423c9d0a..a9ecc2399db 100644 --- a/src/backend/parser/parse_clause.c +++ b/src/backend/parser/parse_clause.c @@ -721,14 +721,15 @@ transformFromClauseItem(ParseState *pstate, Node *n, * we always push them into the namespace, but mark them as not * lateral_ok if the jointype is wrong. * + * Notice that we don't require the merged namespace list to be + * conflict-free. See the comments for scanNameSpaceForRefname(). + * * NB: this coding relies on the fact that list_concat is not * destructive to its second argument. */ lateral_ok = (j->jointype == JOIN_INNER || j->jointype == JOIN_LEFT); setNamespaceLateralState(l_namespace, true, lateral_ok); - checkNameSpaceConflicts(pstate, pstate->p_namespace, l_namespace); - sv_namespace_length = list_length(pstate->p_namespace); pstate->p_namespace = list_concat(pstate->p_namespace, l_namespace); -- cgit v1.2.3