mirror of
https://github.com/postgres/postgres.git
synced 2025-05-17 06:41:24 +03:00
Expand comments and add an assertion in nodeModifyTable.c.
Most comments concern RELKIND_VIEW. One addresses the ExecUpdate() "tupleid" parameter. A later commit will rely on these facts, but they hold already. Back-patch to v12 (all supported versions), the plan for that commit. Reviewed (in an earlier version) by Robert Haas. Discussion: https://postgr.es/m/20240512232923.aa.nmisch@google.com
This commit is contained in:
parent
65aae93c45
commit
c3437fb725
@ -28,6 +28,14 @@
|
||||
* rowtype, but we might still find that different plans are appropriate
|
||||
* for different child relations.
|
||||
*
|
||||
* The relation to modify can be an ordinary table, a view having an
|
||||
* INSTEAD OF trigger, or a foreign table. Earlier processing already
|
||||
* pointed ModifyTable to the underlying relations of any automatically
|
||||
* updatable view not using an INSTEAD OF trigger, so code here can
|
||||
* assume it won't have one as a modification target. This node does
|
||||
* process ri_WithCheckOptions, which may have expressions from those
|
||||
* automatically updatable views.
|
||||
*
|
||||
* If the query specifies RETURNING, then the ModifyTable returns a
|
||||
* RETURNING tuple after completing each row insert, update, or delete.
|
||||
* It must be called again to continue the operation. Without RETURNING,
|
||||
@ -812,8 +820,8 @@ ExecInsert(ModifyTableState *mtstate,
|
||||
* index modifications are needed.
|
||||
*
|
||||
* When deleting from a table, tupleid identifies the tuple to
|
||||
* delete and oldtuple is NULL. When deleting from a view,
|
||||
* oldtuple is passed to the INSTEAD OF triggers and identifies
|
||||
* delete and oldtuple is NULL. When deleting through a view
|
||||
* INSTEAD OF trigger, oldtuple is passed to the triggers and identifies
|
||||
* what to delete, and tupleid is invalid. When deleting from a
|
||||
* foreign table, tupleid is invalid; the FDW has to figure out
|
||||
* which row to delete using data from the planSlot. oldtuple is
|
||||
@ -1178,15 +1186,17 @@ ldelete:;
|
||||
* which corrupts your database..
|
||||
*
|
||||
* When updating a table, tupleid identifies the tuple to
|
||||
* update and oldtuple is NULL. When updating a view, oldtuple
|
||||
* is passed to the INSTEAD OF triggers and identifies what to
|
||||
* update and oldtuple is NULL. When updating through a view INSTEAD OF
|
||||
* trigger, oldtuple is passed to the triggers and identifies what to
|
||||
* update, and tupleid is invalid. When updating a foreign table,
|
||||
* tupleid is invalid; the FDW has to figure out which row to
|
||||
* update using data from the planSlot. oldtuple is passed to
|
||||
* foreign table triggers; it is NULL when the foreign table has
|
||||
* no relevant triggers.
|
||||
*
|
||||
* Returns RETURNING result if any, otherwise NULL.
|
||||
* Returns RETURNING result if any, otherwise NULL. On exit, if tupleid
|
||||
* had identified the tuple to update, it will identify the tuple
|
||||
* actually updated after EvalPlanQual.
|
||||
* ----------------------------------------------------------------
|
||||
*/
|
||||
static TupleTableSlot *
|
||||
@ -2337,8 +2347,8 @@ ExecModifyTable(PlanState *pstate)
|
||||
* to set t_tableOid. Quite separately from this, the FDW may
|
||||
* fetch its own junk attrs to identify the row.
|
||||
*
|
||||
* Other relevant relkinds, currently limited to views, always
|
||||
* have a wholerow attribute.
|
||||
* Other relevant relkinds, currently limited to views having
|
||||
* INSTEAD OF triggers, always have a wholerow attribute.
|
||||
*/
|
||||
else if (AttributeNumberIsValid(junkfilter->jf_junkAttNo))
|
||||
{
|
||||
|
Loading…
x
Reference in New Issue
Block a user