From 27ff4cfe760a79c78eac2948cea67f2ae486cbbf Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Sat, 11 Jan 2014 19:03:15 -0500 Subject: Disallow LATERAL references to the target table of an UPDATE/DELETE. On second thought, commit 0c051c90082da0b7e5bcaf9aabcbd4f361137cdc was over-hasty: rather than allowing this case, we ought to reject it for now. That leaves the field clear for a future feature that allows the target table to be re-specified in the FROM (or USING) clause, which will enable left-joining the target table to something else. We can then also allow LATERAL references to such an explicitly re-specified target table. But allowing them right now will create ambiguities or worse for such a feature, and it isn't something we documented 9.3 as supporting. While at it, add a convenience subroutine to avoid having several copies of the ereport for disalllowed-LATERAL-reference cases. --- src/include/parser/parse_node.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'src/include/parser/parse_node.h') diff --git a/src/include/parser/parse_node.h b/src/include/parser/parse_node.h index 49ca7645d40..6e7928c5251 100644 --- a/src/include/parser/parse_node.h +++ b/src/include/parser/parse_node.h @@ -185,7 +185,8 @@ struct ParseState * inside such a subexpression at the moment.) If p_lateral_ok is not set, * it's an error to actually use such a namespace item. One might think it * would be better to just exclude such items from visibility, but the wording - * of SQL:2008 requires us to do it this way. + * of SQL:2008 requires us to do it this way. We also use p_lateral_ok to + * forbid LATERAL references to an UPDATE/DELETE target table. * * At no time should a namespace list contain two entries that conflict * according to the rules in checkNameSpaceConflicts; but note that those -- cgit v1.2.3