database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-29 10:41:53 +03:00
Code Activity

Split the processing of INSERT/UPDATE/DELETE operations out of execMain.c.

Browse Source 
They are now handled by a new plan node type called ModifyTable, which is
placed at the top of the plan tree.  In itself this change doesn't do much,
except perhaps make the handling of RETURNING lists and inherited UPDATEs a
tad less klugy.  But it is necessary preparation for the intended extension of
allowing RETURNING queries inside WITH.

Marko Tiikkaja
This commit is contained in:
Tom Lane
2009-10-10 01:43:50 +00:00
parent b865d27582
commit 8a5849b7ff
30 changed files with 1546 additions and 1101 deletions
Download Patch File Download Diff File Expand all files Collapse all files

31
src/backend/optimizer/plan/setrefs.c
View File

@ -9,7 +9,7 @@
*
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/optimizer/plan/setrefs.c,v 1.150 2009/06/11 14:48:59 momjian Exp $
* $PostgreSQL: pgsql/src/backend/optimizer/plan/setrefs.c,v 1.151 2009/10/10 01:43:49 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@ -442,6 +442,29 @@ set_plan_refs(PlannerGlobal *glob, Plan *plan, int rtoffset)
fix_scan_expr(glob, splan->resconstantqual, rtoffset);
}
break;
case T_ModifyTable:
{
ModifyTable *splan = (ModifyTable *) plan;
/*
* planner.c already called set_returning_clause_references,
* so we should not process either the targetlist or the
* returningLists.
*/
Assert(splan->plan.qual == NIL);
foreach(l, splan->resultRelations)
{
lfirst_int(l) += rtoffset;
}
foreach(l, splan->plans)
{
lfirst(l) = set_plan_refs(glob,
(Plan *) lfirst(l),
rtoffset);
}
}
break;
case T_Append:
{
Append *splan = (Append *) plan;
@ -1600,7 +1623,7 @@ fix_upper_expr_mutator(Node *node, fix_upper_expr_context *context)
*
* If the query involves more than just the result table, we have to
* adjust any Vars that refer to other tables to reference junk tlist
* entries in the top plan's targetlist. Vars referencing the result
* entries in the top subplan's targetlist. Vars referencing the result
* table should be left alone, however (the executor will evaluate them
* using the actual heap tuple, after firing triggers if any). In the
* adjusted RETURNING list, result-table Vars will still have their
@ -1610,8 +1633,8 @@ fix_upper_expr_mutator(Node *node, fix_upper_expr_context *context)
* glob->relationOids.
*
* 'rlist': the RETURNING targetlist to be fixed
* 'topplan': the top Plan node for the query (not yet passed through
* set_plan_references)
* 'topplan': the top subplan node that will be just below the ModifyTable
* node (note it's not yet passed through set_plan_references)
* 'resultRelation': RT index of the associated result relation
*
* Note: we assume that result relations will have rtoffset zero, that is,