database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-25 01:02:05 +03:00
Code Activity

Fix LATERAL references to target table of UPDATE/DELETE.

Browse Source 
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.
This commit is contained in:
Tom Lane
2014-01-07 15:25:16 -05:00
parent f68220df92
commit 0c051c9008
5 changed files with 95 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
src/backend/parser/analyze.c
View File

@ -342,6 +342,7 @@ static Query *
transformDeleteStmt(ParseState *pstate, DeleteStmt *stmt)
{
Query *qry = makeNode(Query);
ParseNamespaceItem *nsitem;
Node *qual;
qry->commandType = CMD_DELETE;
@ -360,8 +361,15 @@ transformDeleteStmt(ParseState *pstate, DeleteStmt *stmt)
true,
ACL_DELETE);
/* grab the namespace item made by setTargetTable */
nsitem = (ParseNamespaceItem *) llast(pstate->p_namespace);
/* there's no DISTINCT in DELETE */
qry->distinctClause = NIL;
/* subqueries in USING can see the result relation only via LATERAL */
nsitem->p_lateral_only = true;
/*
* The USING clause is non-standard SQL syntax, and is equivalent in
* functionality to the FROM list that can be specified for UPDATE. The
@ -370,6 +378,9 @@ transformDeleteStmt(ParseState *pstate, DeleteStmt *stmt)
*/
transformFromClause(pstate, stmt->usingClause);
/* remaining clauses can see the result relation normally */
nsitem->p_lateral_only = false;
qual = transformWhereClause(pstate, stmt->whereClause,
EXPR_KIND_WHERE, "WHERE");
@ -1889,6 +1900,7 @@ static Query *
transformUpdateStmt(ParseState *pstate, UpdateStmt *stmt)
{
Query *qry = makeNode(Query);
ParseNamespaceItem *nsitem;
RangeTblEntry *target_rte;
Node *qual;
ListCell *origTargetList;
@ -1910,12 +1922,21 @@ transformUpdateStmt(ParseState *pstate, UpdateStmt *stmt)
true,
ACL_UPDATE);
/* grab the namespace item made by setTargetTable */
nsitem = (ParseNamespaceItem *) llast(pstate->p_namespace);
/* subqueries in FROM can see the result relation only via LATERAL */
nsitem->p_lateral_only = true;
/*
* the FROM clause is non-standard SQL syntax. We used to be able to do
* this with REPLACE in POSTQUEL so we keep the feature.
*/
transformFromClause(pstate, stmt->fromClause);
/* remaining clauses can see the result relation normally */
nsitem->p_lateral_only = false;
qry->targetList = transformTargetList(pstate, stmt->targetList,
EXPR_KIND_UPDATE_SOURCE);

4
src/backend/parser/parse_clause.c
View File

@ -204,6 +204,10 @@ setTargetTable(ParseState *pstate, RangeVar *relation,
/*
* If UPDATE/DELETE, add table to joinlist and namespace.
*
* 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.
*/
if (alsoSource)
addRTEtoQuery(pstate, rte, true, true, true);

4
src/backend/parser/parse_relation.c
View File

@ -1730,6 +1730,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,