From 0a43e5466ca03fce433309c6de2a4272b79c1abb Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Tue, 7 Jan 2014 15:25:19 -0500 Subject: Fix LATERAL references to target table of UPDATE/DELETE. I failed to think much about UPDATE/DELETE when implementing LATERAL :-(. The implemented behavior ended up being that subqueries in the FROM or USING clause (respectively) could access the update/delete target table as though it were a lateral reference; which seems fine if they said LATERAL, but certainly ought to draw an error if they didn't. Fix it so you get a suitable error when you omit LATERAL. Per report from Emre Hasegeli. --- src/backend/parser/parse_relation.c | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'src/backend/parser/parse_relation.c') diff --git a/src/backend/parser/parse_relation.c b/src/backend/parser/parse_relation.c index d473749e303..8bd3a90feaf 100644 --- a/src/backend/parser/parse_relation.c +++ b/src/backend/parser/parse_relation.c @@ -1611,6 +1611,10 @@ isLockedRefname(ParseState *pstate, const char *refname) * and/or namespace list. (We assume caller has checked for any * namespace conflicts.) The RTE is always marked as unconditionally * visible, that is, not LATERAL-only. + * + * Note: some callers know that they can find the new ParseNamespaceItem + * at the end of the pstate->p_namespace list. This is a bit ugly but not + * worth complicating this function's signature for. */ void addRTEtoQuery(ParseState *pstate, RangeTblEntry *rte, -- cgit v1.2.3