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.

1 files changed, 2 insertions, 1 deletions

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