diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2014-01-11 19:03:12 -0500 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2014-01-11 19:03:12 -0500 |
commit | 158b7fa6a34006bdc70b515e14e120d3e896589b (patch) | |
tree | 4cc53f3251ed648fa2aaa4adc8afad52b7b1629b /src/backend/parser/analyze.c | |
parent | 910bac5953012198e210848660ea31f27ab08abc (diff) | |
download | postgresql-158b7fa6a34006bdc70b515e14e120d3e896589b.tar.gz postgresql-158b7fa6a34006bdc70b515e14e120d3e896589b.zip |
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.
Diffstat (limited to 'src/backend/parser/analyze.c')
-rw-r--r-- | src/backend/parser/analyze.c | 12 |
1 files changed, 8 insertions, 4 deletions
diff --git a/src/backend/parser/analyze.c b/src/backend/parser/analyze.c index 0d6e661ec42..7225bb62ab0 100644 --- a/src/backend/parser/analyze.c +++ b/src/backend/parser/analyze.c @@ -367,8 +367,9 @@ transformDeleteStmt(ParseState *pstate, DeleteStmt *stmt) /* there's no DISTINCT in DELETE */ qry->distinctClause = NIL; - /* subqueries in USING can see the result relation only via LATERAL */ + /* subqueries in USING cannot access the result relation */ nsitem->p_lateral_only = true; + nsitem->p_lateral_ok = false; /* * The USING clause is non-standard SQL syntax, and is equivalent in @@ -378,8 +379,9 @@ transformDeleteStmt(ParseState *pstate, DeleteStmt *stmt) */ transformFromClause(pstate, stmt->usingClause); - /* remaining clauses can see the result relation normally */ + /* remaining clauses can reference the result relation normally */ nsitem->p_lateral_only = false; + nsitem->p_lateral_ok = true; qual = transformWhereClause(pstate, stmt->whereClause, EXPR_KIND_WHERE, "WHERE"); @@ -1925,8 +1927,9 @@ transformUpdateStmt(ParseState *pstate, UpdateStmt *stmt) /* grab the namespace item made by setTargetTable */ nsitem = (ParseNamespaceItem *) llast(pstate->p_namespace); - /* subqueries in FROM can see the result relation only via LATERAL */ + /* subqueries in FROM cannot access the result relation */ nsitem->p_lateral_only = true; + nsitem->p_lateral_ok = false; /* * the FROM clause is non-standard SQL syntax. We used to be able to do @@ -1934,8 +1937,9 @@ transformUpdateStmt(ParseState *pstate, UpdateStmt *stmt) */ transformFromClause(pstate, stmt->fromClause); - /* remaining clauses can see the result relation normally */ + /* remaining clauses can reference the result relation normally */ nsitem->p_lateral_only = false; + nsitem->p_lateral_ok = true; qry->targetList = transformTargetList(pstate, stmt->targetList, EXPR_KIND_UPDATE_SOURCE); |