| blob | 88c479c6da33a07ec57f0d2627e304fbf8a960e8 |
1 /*-------------------------------------------------------------------------
2 *
3 * nodeModifyTable.c
4 * routines to handle ModifyTable nodes.
5 *
6 * Portions Copyright (c) 1996-2021, PostgreSQL Global Development Group
7 * Portions Copyright (c) 1994, Regents of the University of California
8 *
9 *
10 * IDENTIFICATION
11 * src/backend/executor/nodeModifyTable.c
12 *
13 *-------------------------------------------------------------------------
14 */
15 /* INTERFACE ROUTINES
16 * ExecInitModifyTable - initialize the ModifyTable node
17 * ExecModifyTable - retrieve the next tuple from the node
18 * ExecEndModifyTable - shut down the ModifyTable node
19 * ExecReScanModifyTable - rescan the ModifyTable node
20 *
21 * NOTES
22 * The ModifyTable node receives input from its outerPlan, which is
23 * the data to insert for INSERT cases, or the changed columns' new
24 * values plus row-locating info for UPDATE cases, or just the
25 * row-locating info for DELETE cases.
26 *
27 * If the query specifies RETURNING, then the ModifyTable returns a
28 * RETURNING tuple after completing each row insert, update, or delete.
29 * It must be called again to continue the operation. Without RETURNING,
30 * we just loop within the node until all the work is done, then
31 * return NULL. This avoids useless call/return overhead.
32 */
58 {
72 ItemPointer conflictTid,
85 /*
86 * Verify that the tuples to be produced by INSERT match the
87 * target relation's rowtype
88 *
89 * We do this to guard against stale plans. If plan invalidation is
90 * functioning properly then we should never get a failure here, but better
91 * safe than sorry. Note that this is called after we have obtained lock
92 * on the target rel, so the rowtype can't change underneath us.
93 *
94 * The plan output is represented by its targetlist, because that makes
95 * handling the dropped-column case easier.
96 *
97 * We used to use this for UPDATE as well, but now the equivalent checks
98 * are done in ExecBuildUpdateProjection.
99 */
100 static void
102 {
108 {
110 Form_pg_attribute attr;
120 attno++;
123 {
124 /* Normal case: demand type match */
131 attno,
133 }
134 else
135 {
136 /*
137 * For a dropped column, we can't check atttypid (it's likely 0).
138 * In any case the planner has most likely inserted an INT4 null.
139 * What we insist on is just *some* NULL constant.
140 */
147 attno)));
148 }
149 }
155 }
157 /*
158 * ExecProcessReturning --- evaluate a RETURNING list
159 *
160 * resultRelInfo: current result rel
161 * tupleSlot: slot holding tuple actually inserted/updated/deleted
162 * planSlot: slot holding tuple returned by top subplan node
163 *
164 * Note: If tupleSlot is NULL, the FDW should have already provided econtext's
165 * scan tuple.
166 *
167 * Returns a slot holding the result tuple
168 */
173 {
177 /* Make tuple and any needed join variables available to ExecProject */
182 /*
183 * RETURNING expressions might reference the tableoid column, so
184 * reinitialize tts_tableOid before evaluating them.
185 */
189 /* Compute the RETURNING expressions */
191 }
193 /*
194 * ExecCheckTupleVisible -- verify tuple is visible
195 *
196 * It would not be consistent with guarantees of the higher isolation levels to
197 * proceed with avoiding insertion (taking speculative insertion's alternative
198 * path) on the basis of another tuple that is not visible to MVCC snapshot.
199 * Check for the need to raise a serialization failure, and do so as necessary.
200 */
201 static void
203 Relation rel,
205 {
210 {
211 Datum xminDatum;
212 TransactionId xmin;
219 /*
220 * We should not raise a serialization failure if the conflict is
221 * against a tuple inserted by our own transaction, even if it's not
222 * visible to our snapshot. (This would happen, for example, if
223 * conflicting keys are proposed for insertion in a single command.)
224 */
229 }
230 }
232 /*
233 * ExecCheckTIDVisible -- convenience variant of ExecCheckTupleVisible()
234 */
235 static void
238 ItemPointer tid,
240 {
243 /* Redundantly check isolation level */
251 }
253 /*
254 * Compute stored generated columns for a tuple
255 */
256 void
259 CmdType cmdtype)
260 {
264 MemoryContext oldContext;
270 /*
271 * If first time through for this result relation, build expression
272 * nodetrees for rel's stored generation expressions. Keep them in the
273 * per-query memory context so they'll survive throughout the query.
274 */
276 {
284 {
286 {
289 /*
290 * If it's an update and the current column was not marked as
291 * being updated, then we can skip the computation. But if
292 * there is a BEFORE ROW UPDATE trigger, we cannot skip
293 * because the trigger might affect additional columns.
294 */
299 {
302 }
311 }
312 }
315 }
317 /*
318 * If no generated columns have been affected by this change, then skip
319 * the rest.
320 */
333 {
338 {
340 Datum val;
348 /*
349 * We must make a copy of val as we have no guarantees about where
350 * memory for a pass-by-reference Datum is located.
351 */
357 }
358 else
359 {
362 }
363 }
372 }
374 /*
375 * ExecInitInsertProjection
376 * Do one-time initialization of projection data for INSERT tuples.
377 *
378 * INSERT queries may need a projection to filter out junk attrs in the tlist.
379 *
380 * This is also a convenient place to verify that the
381 * output of an INSERT matches the target table.
382 */
383 static void
386 {
394 /* Extract non-junk columns of the subplan's result tlist. */
396 {
401 else
403 }
405 /*
406 * The junk-free list must produce a tuple suitable for the result
407 * relation.
408 */
411 /* We'll need a slot matching the table's format. */
416 /* Build ProjectionInfo if needed (it probably isn't). */
418 {
421 /* need an expression context to do the projection */
430 relDesc);
431 }
434 }
436 /*
437 * ExecInitUpdateProjection
438 * Do one-time initialization of projection data for UPDATE tuples.
439 *
440 * UPDATE always needs a projection, because (1) there's always some junk
441 * attrs, and (2) we may need to merge values of not-updated columns from
442 * the old tuple into the final tuple. In UPDATE, the tuple arriving from
443 * the subplan contains only new values for the changed columns, plus row
444 * identity info in the junk attrs.
445 *
446 * This is "one-time" for any given result rel, but we might touch more than
447 * one result rel in the course of an inherited UPDATE, and each one needs
448 * its own projection due to possible column order variation.
449 *
450 * This is also a convenient place to verify that the output of an UPDATE
451 * matches the target table (ExecBuildUpdateProjection does that).
452 */
453 static void
456 {
464 /*
465 * Usually, mt_lastResultIndex matches the target rel. If it happens not
466 * to, we can get the index the hard way with an integer division.
467 */
470 {
473 }
477 /*
478 * For UPDATE, we use the old tuple to fill up missing values in the tuple
479 * produced by the subplan to get the new tuple. We need two slots, both
480 * matching the table's desired format.
481 */
489 /* need an expression context to do the projection */
496 updateColnos,
497 relDesc,
503 }
505 /*
506 * ExecGetInsertNewTuple
507 * This prepares a "new" tuple ready to be inserted into given result
508 * relation, by removing any junk columns of the plan's output tuple
509 * and (if necessary) coercing the tuple to the right tuple format.
510 */
514 {
518 /*
519 * If there's no projection to be done, just make sure the slot is of the
520 * right type for the target rel. If the planSlot is the right type we
521 * can use it as-is, else copy the data into ri_newTupleSlot.
522 */
524 {
526 {
529 }
530 else
532 }
534 /*
535 * Else project; since the projection output slot is ri_newTupleSlot, this
536 * will also fix any slot-type problem.
537 *
538 * Note: currently, this is dead code, because INSERT cases don't receive
539 * any junk columns so there's never a projection to be done.
540 */
544 }
546 /*
547 * ExecGetUpdateNewTuple
548 * This prepares a "new" tuple by combining an UPDATE subplan's output
549 * tuple (which contains values of changed columns) with unchanged
550 * columns taken from the old tuple.
551 *
552 * The subplan tuple might also contain junk columns, which are ignored.
553 * Note that the projection also ensures we have a slot of the right type.
554 */
555 TupleTableSlot *
559 {
563 /* Use a few extra Asserts to protect against outside callers */
572 }
575 /* ----------------------------------------------------------------
576 * ExecInsert
577 *
578 * For INSERT, we have to insert the tuple into the target relation
579 * (or partition thereof) and insert appropriate tuples into the index
580 * relations.
581 *
582 * slot contains the new tuple value to be stored.
583 * planSlot is the output of the ModifyTable's subplan; we use it
584 * to access "junk" columns that are not going to be stored.
585 *
586 * Returns RETURNING result if any, otherwise NULL.
587 *
588 * This may change the currently active tuple conversion map in
589 * mtstate->mt_transition_capture, so the callers must take care to
590 * save the previous value to avoid losing track of it.
591 * ----------------------------------------------------------------
592 */
600 {
601 Relation resultRelationDesc;
608 MemoryContext oldContext;
610 /*
611 * If the input result relation is a partitioned table, find the leaf
612 * partition to insert the tuple into.
613 */
615 {
622 }
628 /*
629 * Open the table's indexes, if we have not done so already, so that we
630 * can add new index entries for the inserted tuple.
631 */
636 /*
637 * BEFORE ROW INSERT Triggers.
638 *
639 * Note: We fire BEFORE ROW TRIGGERS for every attempted insertion in an
640 * INSERT ... ON CONFLICT statement. We cannot check for constraint
641 * violations before firing these triggers, because they can change the
642 * values to insert. Also, they can run arbitrary user-defined code with
643 * side-effects that we can't cancel by just not inserting the tuple.
644 */
647 {
650 }
652 /* INSTEAD OF ROW INSERT Triggers */
655 {
658 }
660 {
661 /*
662 * GENERATED expressions might reference the tableoid column, so
663 * (re-)initialize tts_tableOid before evaluating them.
664 */
667 /*
668 * Compute stored generated columns
669 */
673 CMD_INSERT);
675 /*
676 * If the FDW supports batching, and batching is requested, accumulate
677 * rows and insert them in batches. Otherwise use the per-row inserts.
678 */
680 {
681 /*
682 * If a certain number of tuples have already been accumulated, or
683 * a tuple has come for a different relation than that for the
684 * accumulated tuples, perform the batch insert
685 */
687 {
694 }
699 {
704 }
706 /*
707 * Initialize the batch slots. We don't know how many slots will be
708 * needed, so we initialize them as the batch grows, and we keep
709 * them across batches. To mitigate an inefficiency in how resource
710 * owner handles objects with many references (as with many slots
711 * all referencing the same tuple descriptor) we copy the tuple
712 * descriptor for each slot.
713 */
715 {
721 slot);
726 planSlot);
728 /* remember how many batch slots we initialized */
730 }
737 }
739 /*
740 * insert into foreign table: let the FDW do it
741 */
743 resultRelInfo,
744 slot,
745 planSlot);
750 /*
751 * AFTER ROW Triggers or RETURNING expressions might reference the
752 * tableoid column, so (re-)initialize tts_tableOid before evaluating
753 * them. (This covers the case where the FDW replaced the slot.)
754 */
756 }
757 else
758 {
759 WCOKind wco_kind;
761 /*
762 * Constraints and GENERATED expressions might reference the tableoid
763 * column, so (re-)initialize tts_tableOid before evaluating them.
764 */
767 /*
768 * Compute stored generated columns
769 */
773 CMD_INSERT);
775 /*
776 * Check any RLS WITH CHECK policies.
777 *
778 * Normally we should check INSERT policies. But if the insert is the
779 * result of a partition key update that moved the tuple to a new
780 * partition, we should instead check UPDATE policies, because we are
781 * executing policies defined on the target table, and not those
782 * defined on the child partitions.
783 */
787 /*
788 * ExecWithCheckOptions() will skip any WCOs which are not of the kind
789 * we are looking for at this point.
790 */
794 /*
795 * Check the constraints of the tuple.
796 */
800 /*
801 * Also check the tuple against the partition constraint, if there is
802 * one; except that if we got here via tuple-routing, we don't need to
803 * if there's no BR trigger defined on the partition.
804 */
812 {
813 /* Perform a speculative insertion. */
814 uint32 specToken;
815 ItemPointerData conflictTid;
821 /*
822 * Do a non-conclusive check for conflicts first.
823 *
824 * We're not holding any locks yet, so this doesn't guarantee that
825 * the later insert won't conflict. But it avoids leaving behind
826 * a lot of canceled speculative insertions, if you run a lot of
827 * INSERT ON CONFLICT statements that do conflict.
828 *
829 * We loop back here if we find a conflict below, either during
830 * the pre-check, or when we re-check after inserting the tuple
831 * speculatively.
832 */
833 vlock:
837 {
838 /* committed conflict tuple found */
840 {
841 /*
842 * In case of ON CONFLICT DO UPDATE, execute the UPDATE
843 * part. Be prepared to retry if the UPDATE fails because
844 * of another concurrent UPDATE/DELETE to the conflict
845 * tuple.
846 */
852 {
855 }
856 else
858 }
859 else
860 {
861 /*
862 * In case of ON CONFLICT DO NOTHING, do nothing. However,
863 * verify that the tuple is visible to the executor's MVCC
864 * snapshot at higher isolation levels.
865 *
866 * Using ExecGetReturningSlot() to store the tuple for the
867 * recheck isn't that pretty, but we can't trivially use
868 * the input slot, because it might not be of a compatible
869 * type. As there's no conflicting usage of
870 * ExecGetReturningSlot() in the DO NOTHING case...
871 */
877 }
878 }
880 /*
881 * Before we start insertion proper, acquire our "speculative
882 * insertion lock". Others can use that to wait for us to decide
883 * if we're going to go ahead with the insertion, instead of
884 * waiting for the whole transaction to complete.
885 */
888 /* insert the tuple, with the speculative token */
892 NULL,
893 specToken);
895 /* insert index entries for tuple */
899 arbiterIndexes);
901 /* adjust the tuple's state accordingly */
905 /*
906 * Wake up anyone waiting for our decision. They will re-check
907 * the tuple, see that it's no longer speculative, and wait on our
908 * XID as if this was a regularly inserted tuple all along. Or if
909 * we killed the tuple, they will see it's dead, and proceed as if
910 * the tuple never existed.
911 */
914 /*
915 * If there was a conflict, start from the beginning. We'll do
916 * the pre-check again, which will now find the conflicting tuple
917 * (unless it aborts before we get there).
918 */
920 {
923 }
925 /* Since there was no insertion conflict, we're done */
926 }
927 else
928 {
929 /* insert the tuple normally */
934 /* insert index entries for tuple */
939 }
940 }
945 /*
946 * If this insert is the result of a partition key update that moved the
947 * tuple to a new partition, put this row into the transition NEW TABLE,
948 * if there is one. We need to do this separately for DELETE and INSERT
949 * because they happen on different tables.
950 */
954 {
956 NULL,
957 slot,
958 NULL,
961 /*
962 * We've already captured the NEW TABLE row, so make sure any AR
963 * INSERT trigger fired below doesn't capture it again.
964 */
966 }
968 /* AFTER ROW INSERT Triggers */
970 ar_insert_trig_tcs);
974 /*
975 * Check any WITH CHECK OPTION constraints from parent views. We are
976 * required to do this after testing all constraints and uniqueness
977 * violations per the SQL spec, so we do it after actually inserting the
978 * record into the heap and all indexes.
979 *
980 * ExecWithCheckOptions will elog(ERROR) if a violation is found, so the
981 * tuple will never be seen, if it violates the WITH CHECK OPTION.
982 *
983 * ExecWithCheckOptions() will skip any WCOs which are not of the kind we
984 * are looking for at this point.
985 */
989 /* Process RETURNING if present */
994 }
996 /* ----------------------------------------------------------------
997 * ExecBatchInsert
998 *
999 * Insert multiple tuples in an efficient way.
1000 * Currently, this handles inserting into a foreign table without
1001 * RETURNING clause.
1002 * ----------------------------------------------------------------
1003 */
1004 static void
1012 {
1018 /*
1019 * insert into foreign table: let the FDW do it
1020 */
1022 resultRelInfo,
1023 slots,
1024 planSlots,
1028 {
1031 /*
1032 * AFTER ROW Triggers or RETURNING expressions might reference the
1033 * tableoid column, so (re-)initialize tts_tableOid before evaluating
1034 * them.
1035 */
1038 /* AFTER ROW INSERT Triggers */
1042 /*
1043 * Check any WITH CHECK OPTION constraints from parent views. See the
1044 * comment in ExecInsert.
1045 */
1048 }
1052 }
1054 /* ----------------------------------------------------------------
1055 * ExecDelete
1056 *
1057 * DELETE is like UPDATE, except that we delete the tuple and no
1058 * index modifications are needed.
1059 *
1060 * When deleting from a table, tupleid identifies the tuple to
1061 * delete and oldtuple is NULL. When deleting from a view,
1062 * oldtuple is passed to the INSTEAD OF triggers and identifies
1063 * what to delete, and tupleid is invalid. When deleting from a
1064 * foreign table, tupleid is invalid; the FDW has to figure out
1065 * which row to delete using data from the planSlot. oldtuple is
1066 * passed to foreign table triggers; it is NULL when the foreign
1067 * table has no relevant triggers. We use tupleDeleted to indicate
1068 * whether the tuple is actually deleted, callers can use it to
1069 * decide whether to continue the operation. When this DELETE is a
1070 * part of an UPDATE of partition-key, then the slot returned by
1071 * EvalPlanQual() is passed back using output parameter epqslot.
1072 *
1073 * Returns RETURNING result if any, otherwise NULL.
1074 * ----------------------------------------------------------------
1075 */
1079 ItemPointer tupleid,
1080 HeapTuple oldtuple,
1089 {
1091 TM_Result result;
1092 TM_FailureData tmfd;
1099 /* BEFORE ROW DELETE Triggers */
1102 {
1110 }
1112 /* INSTEAD OF ROW DELETE Triggers */
1115 {
1123 }
1125 {
1126 /*
1127 * delete from foreign table: let the FDW do it
1128 *
1129 * We offer the returning slot as a place to store RETURNING data,
1130 * although the FDW can return some other slot if it wants.
1131 */
1134 resultRelInfo,
1135 slot,
1136 planSlot);
1141 /*
1142 * RETURNING expressions might reference the tableoid column, so
1143 * (re)initialize tts_tableOid before evaluating them.
1144 */
1149 }
1150 else
1151 {
1152 /*
1153 * delete the tuple
1154 *
1155 * Note: if es_crosscheck_snapshot isn't InvalidSnapshot, we check
1156 * that the row to be deleted is visible to that snapshot, and throw a
1157 * can't-serialize error if not. This is a special-case behavior
1158 * needed for referential integrity updates in transaction-snapshot
1159 * mode transactions.
1160 */
1161 ldelete:;
1168 changingPart);
1171 {
1174 /*
1175 * The target tuple was already updated or deleted by the
1176 * current command, or by a later command in the current
1177 * transaction. The former case is possible in a join DELETE
1178 * where multiple tuples join to the same target tuple. This
1179 * is somewhat questionable, but Postgres has always allowed
1180 * it: we just ignore additional deletion attempts.
1181 *
1182 * The latter case arises if the tuple is modified by a
1183 * command in a BEFORE trigger, or perhaps by a command in a
1184 * volatile function used in the query. In such situations we
1185 * should not ignore the deletion, but it is equally unsafe to
1186 * proceed. We don't want to discard the original DELETE
1187 * while keeping the triggered actions based on its deletion;
1188 * and it would be no better to allow the original DELETE
1189 * while discarding updates that it triggered. The row update
1190 * carries some information that might be important according
1191 * to business rules; so throwing an error is the only safe
1192 * course.
1193 *
1194 * If a trigger actually intends this type of interaction, it
1195 * can re-execute the DELETE and then return NULL to cancel
1196 * the outer delete.
1197 */
1201 errmsg("tuple to be deleted was already modified by an operation triggered by the current command"),
1202 errhint("Consider using an AFTER trigger instead of a BEFORE trigger to propagate changes to other rows.")));
1204 /* Else, already deleted by self; nothing to do */
1211 {
1220 /*
1221 * Already know that we're going to need to do EPQ, so
1222 * fetch tuple directly into the right slot.
1223 */
1232 TUPLE_LOCK_FLAG_FIND_LAST_VERSION,
1236 {
1240 resultRelationDesc,
1242 inputslot);
1244 /* Tuple not passing quals anymore, exiting... */
1247 /*
1248 * If requested, skip delete and pass back the
1249 * updated row.
1250 */
1252 {
1255 }
1256 else
1261 /*
1262 * This can be reached when following an update
1263 * chain from a tuple updated by another session,
1264 * reaching a tuple that was already updated in
1265 * this transaction. If previously updated by this
1266 * command, ignore the delete, otherwise error
1267 * out.
1268 *
1269 * See also TM_SelfModified response to
1270 * table_tuple_delete() above.
1271 */
1275 errmsg("tuple to be deleted was already modified by an operation triggered by the current command"),
1276 errhint("Consider using an AFTER trigger instead of a BEFORE trigger to propagate changes to other rows.")));
1280 /* tuple already deleted; nothing to do */
1285 /*
1286 * TM_Invisible should be impossible because we're
1287 * waiting for updated row versions, and would
1288 * already have errored out if the first version
1289 * is invisible.
1290 *
1291 * TM_Updated should be impossible, because we're
1292 * locking the latest version via
1293 * TUPLE_LOCK_FLAG_FIND_LAST_VERSION.
1294 */
1296 result);
1298 }
1302 }
1309 /* tuple already deleted; nothing to do */
1314 result);
1316 }
1318 /*
1319 * Note: Normally one would think that we have to delete index tuples
1320 * associated with the heap tuple now...
1321 *
1322 * ... but in POSTGRES, we have no need to do this because VACUUM will
1323 * take care of it later. We can't delete index tuples immediately
1324 * anyway, since the tuple is still visible to other transactions.
1325 */
1326 }
1331 /* Tell caller that the delete actually happened. */
1335 /*
1336 * If this delete is the result of a partition key update that moved the
1337 * tuple to a new partition, put this row into the transition OLD TABLE,
1338 * if there is one. We need to do this separately for DELETE and INSERT
1339 * because they happen on different tables.
1340 */
1344 {
1346 tupleid,
1347 oldtuple,
1348 NULL,
1349 NULL,
1352 /*
1353 * We've already captured the NEW TABLE row, so make sure any AR
1354 * DELETE trigger fired below doesn't capture it again.
1355 */
1357 }
1359 /* AFTER ROW DELETE Triggers */
1361 ar_delete_trig_tcs);
1363 /* Process RETURNING if present and if requested */
1365 {
1366 /*
1367 * We have to put the target tuple into a slot, which means first we
1368 * gotta fetch it. We can use the trigger tuple slot.
1369 */
1373 {
1374 /* FDW must have provided a slot containing the deleted row */
1376 }
1377 else
1378 {
1381 {
1383 }
1384 else
1385 {
1389 }
1390 }
1394 /*
1395 * Before releasing the target tuple again, make sure rslot has a
1396 * local copy of any pass-by-reference values.
1397 */
1403 }
1406 }
1408 /*
1409 * ExecCrossPartitionUpdate --- Move an updated tuple to another partition.
1410 *
1411 * This works by first deleting the old tuple from the current partition,
1412 * followed by inserting the new tuple into the root parent table, that is,
1413 * mtstate->rootResultRelInfo. It will be re-routed from there to the
1414 * correct partition.
1415 *
1416 * Returns true if the tuple has been successfully moved, or if it's found
1417 * that the tuple was concurrently deleted so there's nothing more to do
1418 * for the caller.
1419 *
1420 * False is returned if the tuple we're trying to move is found to have been
1421 * concurrently updated. In that case, the caller must to check if the
1422 * updated tuple that's returned in *retry_slot still needs to be re-routed,
1423 * and call this function again or perform a regular update accordingly.
1424 */
1425 static bool
1433 {
1442 /*
1443 * Disallow an INSERT ON CONFLICT DO UPDATE that causes the original row
1444 * to migrate to a different partition. Maybe this can be implemented
1445 * some day, but it seems a fringe feature with little redeeming value.
1446 */
1451 errdetail("The result tuple would appear in a different partition than the original tuple.")));
1453 /*
1454 * When an UPDATE is run directly on a leaf partition, simply fail with a
1455 * partition constraint violation error.
1456 */
1460 /* Initialize tuple routing info if not already done. */
1462 {
1464 MemoryContext oldcxt;
1466 /* Things built here have to last for the query duration. */
1472 /*
1473 * Before a partition's tuple can be re-routed, it must first be
1474 * converted to the root's format, so we'll need a slot for storing
1475 * such tuples.
1476 */
1481 }
1483 /*
1484 * Row movement, part 1. Delete the tuple, but skip RETURNING processing.
1485 * We want to return rows from INSERT.
1486 */
1494 /*
1495 * For some reason if DELETE didn't happen (e.g. trigger prevented it, or
1496 * it was already deleted by self, or it was concurrently deleted by
1497 * another transaction), then we should skip the insert as well;
1498 * otherwise, an UPDATE could cause an increase in the total number of
1499 * rows across all partitions, which is clearly wrong.
1500 *
1501 * For a normal UPDATE, the case where the tuple has been the subject of a
1502 * concurrent UPDATE or DELETE would be handled by the EvalPlanQual
1503 * machinery, but for an UPDATE that we've translated into a DELETE from
1504 * this partition and an INSERT into some other partition, that's not
1505 * available, because CTID chains can't span relation boundaries. We
1506 * mimic the semantics to a limited extent by skipping the INSERT if the
1507 * DELETE fails to find a tuple. This ensures that two concurrent
1508 * attempts to UPDATE the same tuple at the same time can't turn one tuple
1509 * into two, and that an UPDATE of a just-deleted tuple can't resurrect
1510 * it.
1511 */
1513 {
1514 /*
1515 * epqslot will be typically NULL. But when ExecDelete() finds that
1516 * another transaction has concurrently updated the same row, it
1517 * re-fetches the row, skips the delete, and epqslot is set to the
1518 * re-fetched tuple slot. In that case, we need to do all the checks
1519 * again.
1520 */
1523 else
1524 {
1525 /* Fetch the most recent version of old tuple. */
1528 /* ... but first, make sure ri_oldTupleSlot is initialized. */
1533 tupleid,
1534 SnapshotAny,
1535 oldSlot))
1538 oldSlot);
1540 }
1541 }
1543 /*
1544 * resultRelInfo is one of the per-relation resultRelInfos. So we should
1545 * convert the tuple into root's tuple descriptor if needed, since
1546 * ExecInsert() starts the search from root.
1547 */
1551 slot,
1554 /* Tuple routing starts from the root table. */
1558 /*
1559 * Reset the transition state that may possibly have been written by
1560 * INSERT.
1561 */
1565 /* We're done moving. */
1567 }
1569 /* ----------------------------------------------------------------
1570 * ExecUpdate
1571 *
1572 * note: we can't run UPDATE queries with transactions
1573 * off because UPDATEs are actually INSERTs and our
1574 * scan will mistakenly loop forever, updating the tuple
1575 * it just inserted.. This should be fixed but until it
1576 * is, we don't want to get stuck in an infinite loop
1577 * which corrupts your database..
1578 *
1579 * When updating a table, tupleid identifies the tuple to
1580 * update and oldtuple is NULL. When updating a view, oldtuple
1581 * is passed to the INSTEAD OF triggers and identifies what to
1582 * update, and tupleid is invalid. When updating a foreign table,
1583 * tupleid is invalid; the FDW has to figure out which row to
1584 * update using data from the planSlot. oldtuple is passed to
1585 * foreign table triggers; it is NULL when the foreign table has
1586 * no relevant triggers.
1587 *
1588 * slot contains the new tuple value to be stored.
1589 * planSlot is the output of the ModifyTable's subplan; we use it
1590 * to access values from other input tables (for RETURNING),
1591 * row-ID junk columns, etc.
1592 *
1593 * Returns RETURNING result if any, otherwise NULL.
1594 * ----------------------------------------------------------------
1595 */
1599 ItemPointer tupleid,
1600 HeapTuple oldtuple,
1606 {
1608 TM_Result result;
1609 TM_FailureData tmfd;
1612 /*
1613 * abort the operation if not running transactions
1614 */
1620 /*
1621 * Open the table's indexes, if we have not done so already, so that we
1622 * can add new index entries for the updated tuple.
1623 */
1628 /* BEFORE ROW UPDATE Triggers */
1631 {
1635 }
1637 /* INSTEAD OF ROW UPDATE Triggers */
1640 {
1644 }
1646 {
1647 /*
1648 * GENERATED expressions might reference the tableoid column, so
1649 * (re-)initialize tts_tableOid before evaluating them.
1650 */
1653 /*
1654 * Compute stored generated columns
1655 */
1659 CMD_UPDATE);
1661 /*
1662 * update in foreign table: let the FDW do it
1663 */
1665 resultRelInfo,
1666 slot,
1667 planSlot);
1672 /*
1673 * AFTER ROW Triggers or RETURNING expressions might reference the
1674 * tableoid column, so (re-)initialize tts_tableOid before evaluating
1675 * them. (This covers the case where the FDW replaced the slot.)
1676 */
1678 }
1679 else
1680 {
1681 LockTupleMode lockmode;
1685 /*
1686 * Constraints and GENERATED expressions might reference the tableoid
1687 * column, so (re-)initialize tts_tableOid before evaluating them.
1688 */
1691 /*
1692 * Compute stored generated columns
1693 */
1697 CMD_UPDATE);
1699 /*
1700 * Check any RLS UPDATE WITH CHECK policies
1701 *
1702 * If we generate a new candidate tuple after EvalPlanQual testing, we
1703 * must loop back here and recheck any RLS policies and constraints.
1704 * (We don't need to redo triggers, however. If there are any BEFORE
1705 * triggers then trigger.c will have done table_tuple_lock to lock the
1706 * correct tuple, so there's no need to do them again.)
1707 */
1708 lreplace:;
1710 /* ensure slot is independent, consider e.g. EPQ */
1713 /*
1714 * If partition constraint fails, this row might get moved to another
1715 * partition, in which case we should check the RLS CHECK policy just
1716 * before inserting into the new partition, rather than doing it here.
1717 * This is because a trigger on that partition might again change the
1718 * row. So skip the WCO checks if the partition constraint fails.
1719 */
1720 partition_constraint_failed =
1726 {
1727 /*
1728 * ExecWithCheckOptions() will skip any WCOs which are not of the
1729 * kind we are looking for at this point.
1730 */
1733 }
1735 /*
1736 * If a partition check failed, try to move the row into the right
1737 * partition.
1738 */
1740 {
1745 /*
1746 * ExecCrossPartitionUpdate will first DELETE the row from the
1747 * partition it's currently in and then insert it back into the
1748 * root table, which will re-route it to the correct partition.
1749 * The first part may have to be repeated if it is detected that
1750 * the tuple we're trying to move has been concurrently updated.
1751 */
1757 {
1760 }
1763 }
1765 /*
1766 * Check the constraints of the tuple. We've already checked the
1767 * partition constraint above; however, we must still ensure the tuple
1768 * passes all other constraints, so we will call ExecConstraints() and
1769 * have it validate all remaining checks.
1770 */
1774 /*
1775 * replace the heap tuple
1776 *
1777 * Note: if es_crosscheck_snapshot isn't InvalidSnapshot, we check
1778 * that the row to be updated is visible to that snapshot, and throw a
1779 * can't-serialize error if not. This is a special-case behavior
1780 * needed for referential integrity updates in transaction-snapshot
1781 * mode transactions.
1782 */
1791 {
1794 /*
1795 * The target tuple was already updated or deleted by the
1796 * current command, or by a later command in the current
1797 * transaction. The former case is possible in a join UPDATE
1798 * where multiple tuples join to the same target tuple. This
1799 * is pretty questionable, but Postgres has always allowed it:
1800 * we just execute the first update action and ignore
1801 * additional update attempts.
1802 *
1803 * The latter case arises if the tuple is modified by a
1804 * command in a BEFORE trigger, or perhaps by a command in a
1805 * volatile function used in the query. In such situations we
1806 * should not ignore the update, but it is equally unsafe to
1807 * proceed. We don't want to discard the original UPDATE
1808 * while keeping the triggered actions based on it; and we
1809 * have no principled way to merge this update with the
1810 * previous ones. So throwing an error is the only safe
1811 * course.
1812 *
1813 * If a trigger actually intends this type of interaction, it
1814 * can re-execute the UPDATE (assuming it can figure out how)
1815 * and then return NULL to cancel the outer update.
1816 */
1820 errmsg("tuple to be updated was already modified by an operation triggered by the current command"),
1821 errhint("Consider using an AFTER trigger instead of a BEFORE trigger to propagate changes to other rows.")));
1823 /* Else, already updated by self; nothing to do */
1830 {
1840 /*
1841 * Already know that we're going to need to do EPQ, so
1842 * fetch tuple directly into the right slot.
1843 */
1851 TUPLE_LOCK_FLAG_FIND_LAST_VERSION,
1855 {
1860 resultRelationDesc,
1862 inputslot);
1864 /* Tuple not passing quals anymore, exiting... */
1867 /* Make sure ri_oldTupleSlot is initialized. */
1871 /* Fetch the most recent version of old tuple. */
1874 tupleid,
1875 SnapshotAny,
1876 oldSlot))
1883 /* tuple already deleted; nothing to do */
1888 /*
1889 * This can be reached when following an update
1890 * chain from a tuple updated by another session,
1891 * reaching a tuple that was already updated in
1892 * this transaction. If previously modified by
1893 * this command, ignore the redundant update,
1894 * otherwise error out.
1895 *
1896 * See also TM_SelfModified response to
1897 * table_tuple_update() above.
1898 */
1902 errmsg("tuple to be updated was already modified by an operation triggered by the current command"),
1903 errhint("Consider using an AFTER trigger instead of a BEFORE trigger to propagate changes to other rows.")));
1907 /* see table_tuple_lock call in ExecDelete() */
1909 result);
1911 }
1912 }
1921 /* tuple already deleted; nothing to do */
1926 result);
1928 }
1930 /* insert index entries for tuple if necessary */
1935 }
1940 /* AFTER ROW UPDATE Triggers */
1942 recheckIndexes,
1949 /*
1950 * Check any WITH CHECK OPTION constraints from parent views. We are
1951 * required to do this after testing all constraints and uniqueness
1952 * violations per the SQL spec, so we do it after actually updating the
1953 * record in the heap and all indexes.
1954 *
1955 * ExecWithCheckOptions() will skip any WCOs which are not of the kind we
1956 * are looking for at this point.
1957 */
1961 /* Process RETURNING if present */
1966 }
1968 /*
1969 * ExecOnConflictUpdate --- execute UPDATE of INSERT ON CONFLICT DO UPDATE
1970 *
1971 * Try to lock tuple for update as part of speculative insertion. If
1972 * a qual originating from ON CONFLICT DO UPDATE is satisfied, update
1973 * (but still lock row, even though it may not satisfy estate's
1974 * snapshot).
1975 *
1976 * Returns true if we're done (with or without an update), or false if
1977 * the caller must retry the INSERT from scratch.
1978 */
1979 static bool
1982 ItemPointer conflictTid,
1988 {
1993 TM_FailureData tmfd;
1994 LockTupleMode lockmode;
1995 TM_Result test;
1996 Datum xminDatum;
1997 TransactionId xmin;
2000 /* Determine lock mode to use */
2003 /*
2004 * Lock tuple for update. Don't follow updates when tuple cannot be
2005 * locked without doing so. A row locking conflict here means our
2006 * previous conclusion that the tuple is conclusively committed is not
2007 * true anymore.
2008 */
2015 {
2017 /* success! */
2022 /*
2023 * This can occur when a just inserted tuple is updated again in
2024 * the same command. E.g. because multiple rows with the same
2025 * conflicting key values are inserted.
2026 *
2027 * This is somewhat similar to the ExecUpdate() TM_SelfModified
2028 * case. We do not want to proceed because it would lead to the
2029 * same row being updated a second time in some unspecified order,
2030 * and in contrast to plain UPDATEs there's no historical behavior
2031 * to break.
2032 *
2033 * It is the user's responsibility to prevent this situation from
2034 * occurring. These problems are why SQL-2003 similarly specifies
2035 * that for SQL MERGE, an exception must be raised in the event of
2036 * an attempt to update the same row twice.
2037 */
2039 MinTransactionIdAttributeNumber,
2048 errhint("Ensure that no rows proposed for insertion within the same command have duplicate constrained values.")));
2050 /* This shouldn't happen */
2056 /*
2057 * This state should never be reached. As a dirty snapshot is used
2058 * to find conflicting tuples, speculative insertion wouldn't have
2059 * seen this row to conflict with.
2060 */
2070 /*
2071 * As long as we don't support an UPDATE of INSERT ON CONFLICT for
2072 * a partitioned table we shouldn't reach to a case where tuple to
2073 * be lock is moved to another partition due to concurrent update
2074 * of the partition key.
2075 */
2078 /*
2079 * Tell caller to try again from the very start.
2080 *
2081 * It does not make sense to use the usual EvalPlanQual() style
2082 * loop here, as the new version of the row might not conflict
2083 * anymore, or the conflicting tuple has actually been deleted.
2084 */
2094 /* see TM_Updated case */
2101 }
2103 /* Success, the tuple is locked. */
2105 /*
2106 * Verify that the tuple is visible to our MVCC snapshot if the current
2107 * isolation level mandates that.
2108 *
2109 * It's not sufficient to rely on the check within ExecUpdate() as e.g.
2110 * CONFLICT ... WHERE clause may prevent us from reaching that.
2111 *
2112 * This means we only ever continue when a new command in the current
2113 * transaction could see the row, even though in READ COMMITTED mode the
2114 * tuple will not be visible according to the current statement's
2115 * snapshot. This is in line with the way UPDATE deals with newer tuple
2116 * versions.
2117 */
2120 /*
2121 * Make tuple and any needed join variables available to ExecQual and
2122 * ExecProject. The EXCLUDED tuple is installed in ecxt_innertuple, while
2123 * the target's existing tuple is installed in the scantuple. EXCLUDED
2124 * has been made to reference INNER_VAR in setrefs.c, but there is no
2125 * other redirection.
2126 */
2132 {
2136 }
2139 {
2140 /*
2141 * Check target's existing tuple against UPDATE-applicable USING
2142 * security barrier quals (if any), enforced here as RLS checks/WCOs.
2143 *
2144 * The rewriter creates UPDATE RLS checks/WCOs for UPDATE security
2145 * quals, and stores them as WCOs of "kind" WCO_RLS_CONFLICT_CHECK,
2146 * but that's almost the extent of its special handling for ON
2147 * CONFLICT DO UPDATE.
2148 *
2149 * The rewriter will also have associated UPDATE applicable straight
2150 * RLS checks/WCOs for the benefit of the ExecUpdate() call that
2151 * follows. INSERTs and UPDATEs naturally have mutually exclusive WCO
2152 * kinds, so there is no danger of spurious over-enforcement in the
2153 * INSERT or UPDATE path.
2154 */
2156 existing,
2158 }
2160 /* Project the new tuple version */
2163 /*
2164 * Note that it is possible that the target tuple has been modified in
2165 * this session, after the above table_tuple_lock. We choose to not error
2166 * out in that case, in line with ExecUpdate's treatment of similar cases.
2167 * This can happen if an UPDATE is triggered from within ExecQual(),
2168 * ExecWithCheckOptions() or ExecProject() above, e.g. by selecting from a
2169 * wCTE in the ON CONFLICT's SET.
2170 */
2172 /* Execute UPDATE with projection */
2175 planSlot,
2177 canSetTag);
2179 /*
2180 * Clear out existing tuple, as there might not be another conflict among
2181 * the next input rows. Don't want to hold resources till the end of the
2182 * query.
2183 */
2186 }
2189 /*
2190 * Process BEFORE EACH STATEMENT triggers
2191 */
2192 static void
2194 {
2199 {
2204 resultRelInfo);
2215 }
2216 }
2218 /*
2219 * Process AFTER EACH STATEMENT triggers
2220 */
2221 static void
2223 {
2228 {
2232 resultRelInfo,
2248 }
2249 }
2251 /*
2252 * Set up the state needed for collecting transition tuples for AFTER
2253 * triggers.
2254 */
2255 static void
2257 {
2261 /* Check for transition tables on the directly targeted relation. */
2271 CMD_UPDATE);
2272 }
2274 /*
2275 * ExecPrepareTupleRouting --- prepare for routing one tuple
2276 *
2277 * Determine the partition in which the tuple in slot is to be inserted,
2278 * and return its ResultRelInfo in *partRelInfo. The return value is
2279 * a slot holding the tuple of the partition rowtype.
2280 *
2281 * This also sets the transition table information in mtstate based on the
2282 * selected partition.
2283 */
2291 {
2295 /*
2296 * Lookup the target partition's ResultRelInfo. If ExecFindPartition does
2297 * not find a valid partition for the tuple in 'slot' then an error is
2298 * raised. An error may also be raised if the found partition is not a
2299 * valid target for INSERTs. This is required since a partitioned table
2300 * UPDATE to another partition becomes a DELETE+INSERT.
2301 */
2304 /*
2305 * If we're capturing transition tuples, we might need to convert from the
2306 * partition rowtype to root partitioned table's rowtype. But if there
2307 * are no BEFORE triggers on the partition that could change the tuple, we
2308 * can just remember the original unconverted tuple to avoid a needless
2309 * round trip conversion.
2310 */
2312 {
2320 }
2322 /*
2323 * Convert the tuple, if necessary.
2324 */
2327 {
2331 }
2335 }
2337 /* ----------------------------------------------------------------
2338 * ExecModifyTable
2339 *
2340 * Perform table modifications as required, and return RETURNING results
2341 * if needed.
2342 * ----------------------------------------------------------------
2343 */
2346 {
2355 ItemPointer tupleid;
2356 ItemPointerData tuple_ctid;
2357 HeapTupleData oldtupdata;
2358 HeapTuple oldtuple;
2365 /*
2366 * This should NOT get called during EvalPlanQual; we should have passed a
2367 * subplan tree to EvalPlanQual, instead. Use a runtime test not just
2368 * Assert because this condition is easy to miss in testing. (Note:
2369 * although ModifyTable should not get executed within an EvalPlanQual
2370 * operation, we do have to allow it to be initialized and shut down in
2371 * case it is within a CTE subplan. Hence this test must be here, not in
2372 * ExecInitModifyTable.)
2373 */
2377 /*
2378 * If we've already completed processing, don't try to do more. We need
2379 * this test because ExecPostprocessPlan might call us an extra time, and
2380 * our subplan's nodes aren't necessarily robust against being called
2381 * extra times.
2382 */
2386 /*
2387 * On first call, fire BEFORE STATEMENT triggers before proceeding.
2388 */
2390 {
2393 }
2395 /* Preload local variables */
2399 /*
2400 * Fetch rows from subplan, and execute the required table modification
2401 * for each row.
2402 */
2404 {
2405 /*
2406 * Reset the per-output-tuple exprcontext. This is needed because
2407 * triggers expect to use that context as workspace. It's a bit ugly
2408 * to do this below the top level of the plan, however. We might need
2409 * to rethink this later.
2410 */
2413 /*
2414 * Reset per-tuple memory context used for processing on conflict and
2415 * returning clauses, to free any expression evaluation storage
2416 * allocated in the previous cycle.
2417 */
2423 /* No more tuples to process? */
2427 /*
2428 * When there are multiple result relations, each tuple contains a
2429 * junk column that gives the OID of the rel from which it came.
2430 * Extract it and select the correct result relation.
2431 */
2433 {
2434 Datum datum;
2436 Oid resultoid;
2444 /* If it's not the same as last time, we need to locate the rel */
2448 }
2450 /*
2451 * If resultRelInfo->ri_usesFdwDirectModify is true, all we need to do
2452 * here is compute the RETURNING expressions.
2453 */
2455 {
2458 /*
2459 * A scan slot containing the data that was actually inserted,
2460 * updated or deleted has already been made available to
2461 * ExecProcessReturning by IterateDirectModify, so no need to
2462 * provide it here.
2463 */
2467 }
2475 /*
2476 * For UPDATE/DELETE, fetch the row identity info for the tuple to be
2477 * updated/deleted. For a heap relation, that's a TID; otherwise we
2478 * may have a wholerow junk attr that carries the old tuple in toto.
2479 * Keep this in step with the part of ExecInitModifyTable that sets up
2480 * ri_RowIdAttNo.
2481 */
2483 {
2485 Datum datum;
2492 {
2493 /* ri_RowIdAttNo refers to a ctid attribute */
2498 /* shouldn't ever get a null result... */
2505 }
2507 /*
2508 * Use the wholerow attribute, when available, to reconstruct the
2509 * old relation tuple. The old tuple serves one or both of two
2510 * purposes: 1) it serves as the OLD tuple for row triggers, 2) it
2511 * provides values for any unchanged columns for the NEW tuple of
2512 * an UPDATE, because the subplan does not produce all the columns
2513 * of the target table.
2514 *
2515 * Note that the wholerow attribute does not carry system columns,
2516 * so foreign table triggers miss seeing those, except that we
2517 * know enough here to set t_tableOid. Quite separately from
2518 * this, the FDW may fetch its own junk attrs to identify the row.
2519 *
2520 * Other relevant relkinds, currently limited to views, always
2521 * have a wholerow attribute.
2522 */
2524 {
2528 /* shouldn't ever get a null result... */
2536 /* Historically, view triggers see invalid t_tableOid. */
2542 }
2543 else
2544 {
2545 /* Only foreign tables are allowed to omit a row-ID attr */
2547 }
2548 }
2551 {
2553 /* Initialize projection info if first time for this table */
2561 /* Initialize projection info if first time for this table */
2565 /*
2566 * Make the new tuple by combining plan's output tuple with
2567 * the old tuple being updated.
2568 */
2571 {
2572 /* Use the wholerow junk attr as the old tuple. */
2574 }
2575 else
2576 {
2577 /* Fetch the most recent version of old tuple. */
2582 SnapshotAny,
2583 oldSlot))
2585 }
2587 oldSlot);
2589 /* Now apply the update. */
2605 }
2607 /*
2608 * If we got a RETURNING result, return it to caller. We'll continue
2609 * the work on next call.
2610 */
2613 }
2615 /*
2616 * Insert remaining tuples for batch insert.
2617 */
2620 else
2624 {
2632 }
2634 /*
2635 * We're done, but fire AFTER STATEMENT triggers before exiting.
2636 */
2642 }
2644 /*
2645 * ExecLookupResultRelByOid
2646 * If the table with given OID is among the result relations to be
2647 * updated by the given ModifyTable node, return its ResultRelInfo.
2648 *
2649 * If not found, return NULL if missing_ok, else raise error.
2650 *
2651 * If update_cache is true, then upon successful lookup, update the node's
2652 * one-element cache. ONLY ExecModifyTable may pass true for this.
2653 */
2654 ResultRelInfo *
2657 {
2659 {
2660 /* Use the pre-built hash table to locate the rel */
2666 {
2668 {
2671 }
2673 }
2674 }
2675 else
2676 {
2677 /* With few target rels, just search the ResultRelInfo array */
2679 {
2683 {
2685 {
2688 }
2690 }
2691 }
2692 }
2697 }
2699 /* ----------------------------------------------------------------
2700 * ExecInitModifyTable
2701 * ----------------------------------------------------------------
2702 */
2703 ModifyTableState *
2705 {
2714 Relation rel;
2716 /* check for unsupported flags */
2719 /*
2720 * create state structure
2721 */
2735 /*----------
2736 * Resolve the target relation. This is the same as:
2737 *
2738 * - the relation for which we will fire FOR STATEMENT triggers,
2739 * - the relation into whose tuple format all captured transition tuples
2740 * must be converted, and
2741 * - the root partitioned table used for tuple routing.
2742 *
2743 * If it's a partitioned table, the root partition doesn't appear
2744 * elsewhere in the plan and its RT index is given explicitly in
2745 * node->rootRelation. Otherwise (i.e. table inheritance) the target
2746 * relation is the first relation in the node->resultRelations list.
2747 *----------
2748 */
2750 {
2754 }
2755 else
2756 {
2760 }
2762 /* set up epqstate with dummy subplan data for the moment */
2766 /*
2767 * Build state for collecting transition tuples. This requires having a
2768 * valid trigger query context, so skip it in explain-only mode.
2769 */
2773 /*
2774 * Open all the result relations and initialize the ResultRelInfo structs.
2775 * (But root relation was initialized above, if it's part of the array.)
2776 * We must do this before initializing the subplan, because direct-modify
2777 * FDWs expect their ResultRelInfos to be available.
2778 */
2782 {
2786 {
2789 /*
2790 * For child result relations, store the root result relation
2791 * pointer. We do so for the convenience of places that want to
2792 * look at the query's original target relation but don't have the
2793 * mtstate handy.
2794 */
2796 }
2798 /* Initialize the usesFdwDirectModify flag */
2802 /*
2803 * Verify result relation is a valid target for the current operation
2804 */
2807 resultRelInfo++;
2808 i++;
2809 }
2811 /*
2812 * Now we may initialize the subplan.
2813 */
2816 /*
2817 * Do additional per-result-relation initialization.
2818 */
2820 {
2823 /* Let FDWs init themselves for foreign-table result rels */
2827 {
2831 resultRelInfo,
2832 fdw_private,
2833 i,
2834 eflags);
2835 }
2837 /*
2838 * For UPDATE/DELETE, find the appropriate junk attr now, either a
2839 * 'ctid' or 'wholerow' attribute depending on relkind. For foreign
2840 * tables, the FDW might have created additional junk attr(s), but
2841 * those are no concern of ours.
2842 */
2844 {
2851 {
2856 }
2858 {
2859 /*
2860 * When there is a row-level trigger, there should be a
2861 * wholerow attribute. We also require it to be present in
2862 * UPDATE, so we can get the values of unchanged columns.
2863 */
2870 }
2871 else
2872 {
2873 /* Other valid target relkinds must provide wholerow */
2879 }
2880 }
2881 }
2883 /*
2884 * If this is an inherited update/delete, there will be a junk attribute
2885 * named "tableoid" present in the subplan's targetlist. It will be used
2886 * to identify the result relation for a given tuple to be
2887 * updated/deleted.
2888 */
2895 /* Get the root target relation */
2898 /*
2899 * Build state for tuple routing if it's a partitioned INSERT. An UPDATE
2900 * might need this too, but only if it actually moves tuples between
2901 * partitions; in that case setup is done by ExecCrossPartitionUpdate.
2902 */
2908 /*
2909 * Initialize any WITH CHECK OPTION constraints if needed.
2910 */
2913 {
2919 {
2925 }
2929 resultRelInfo++;
2930 }
2932 /*
2933 * Initialize RETURNING projections if needed.
2934 */
2936 {
2940 /*
2941 * Initialize result tuple slot and assign its rowtype using the first
2942 * RETURNING list. We assume the rest will look the same.
2943 */
2946 /* Set up a slot for the output of the RETURNING projection(s) */
2950 /* Need an econtext too */
2955 /*
2956 * Build a projection for each result rel.
2957 */
2960 {
2967 resultRelInfo++;
2968 }
2969 }
2970 else
2971 {
2972 /*
2973 * We still must construct a dummy result tuple type, because InitPlan
2974 * expects one (maybe should change that?).
2975 */
2980 }
2982 /* Set the list of arbiter indexes if needed for ON CONFLICT */
2985 {
2986 /* insert may only have one relation, inheritance is not expanded */
2989 }
2991 /*
2992 * If needed, Initialize target list, projection and qual for ON CONFLICT
2993 * DO UPDATE.
2994 */
2996 {
2999 TupleDesc relationDesc;
3001 /* already exists if created by RETURNING processing above */
3008 /* create state for DO UPDATE SET operation */
3011 /* initialize slot for the existing tuple */
3016 /*
3017 * Create the tuple slot for the UPDATE SET projection. We want a slot
3018 * of the table's type here, because the slot will be used to insert
3019 * into the table, and for RETURNING processing - which may access
3020 * system attributes.
3021 */
3026 /* build UPDATE SET projection state */
3031 relationDesc,
3032 econtext,
3036 /* initialize state to evaluate the WHERE clause, if any */
3038 {
3044 }
3045 }
3047 /*
3048 * If we have any secondary relations in an UPDATE or DELETE, they need to
3049 * be treated like non-locked relations in SELECT FOR UPDATE, ie, the
3050 * EvalPlanQual mechanism needs to be told about them. Locate the
3051 * relevant ExecRowMarks.
3052 */
3055 {
3060 /* ignore "parent" rowmarks; they are irrelevant at runtime */
3064 /* Find ExecRowMark and build ExecAuxRowMark */
3068 }
3072 /*
3073 * If there are a lot of result relations, use a hash table to speed the
3074 * lookups. If there are not a lot, a simple linear search is faster.
3075 *
3076 * It's not clear where the threshold is, but try 64 for starters. In a
3077 * debugging build, use a small threshold so that we get some test
3078 * coverage of both code paths.
3079 */
3080 #ifdef USE_ASSERT_CHECKING
3081 #define MT_NRELS_HASH 4
3082 #else
3083 #define MT_NRELS_HASH 64
3084 #endif
3086 {
3087 HASHCTL hash_ctl;
3097 {
3098 Oid hashkey;
3109 }
3110 }
3111 else
3114 /*
3115 * Determine if the FDW supports batch insert and determine the batch size
3116 * (a FDW may support batching, but it may be disabled for the
3117 * server/table).
3118 *
3119 * We only do this for INSERT, so that for UPDATE/DELETE the batch size
3120 * remains set to 0.
3121 */
3123 {
3124 /* insert may only have one relation, inheritance is not expanded */
3131 {
3135 }
3136 else
3138 }
3140 /*
3141 * Lastly, if this is not the primary (canSetTag) ModifyTable node, add it
3142 * to estate->es_auxmodifytables so that it will be run to completion by
3143 * ExecPostprocessPlan. (It'd actually work fine to add the primary
3144 * ModifyTable node too, but there's no need.) Note the use of lcons not
3145 * lappend: we need later-initialized ModifyTable nodes to be shut down
3146 * before earlier ones. This ensures that we don't throw away RETURNING
3147 * rows that need to be seen by a later CTE subplan.
3148 */
3154 }
3156 /* ----------------------------------------------------------------
3157 * ExecEndModifyTable
3158 *
3159 * Shuts down the plan.
3160 *
3161 * Returns nothing of interest.
3162 * ----------------------------------------------------------------
3163 */
3164 void
3166 {
3169 /*
3170 * Allow any FDWs to shut down
3171 */
3173 {
3181 resultRelInfo);
3183 /*
3184 * Cleanup the initialized batch slots. This only matters for FDWs with
3185 * batching, but the other cases will have ri_NumSlotsInitialized == 0.
3186 */
3188 {
3191 }
3192 }
3194 /*
3195 * Close all the partitioned tables, leaf partitions, and their indices
3196 * and release the slot used for tuple routing, if set.
3197 */
3199 {
3204 }
3206 /*
3207 * Free the exprcontext
3208 */
3211 /*
3212 * clean out the tuple table
3213 */
3217 /*
3218 * Terminate EPQ execution if active
3219 */
3222 /*
3223 * shut down subplan
3224 */
3226 }
3228 void
3230 {
3231 /*
3232 * Currently, we don't need to support rescan on ModifyTable nodes. The
3233 * semantics of that would be a bit debatable anyway.
3234 */
3236 }