{"Entry":{"collection":"plan","key":"modifytable","name":"ModifyTable","aliases":["Delete","Insert","Merge","ModifyTable","T_ModifyTable","Update"],"metadata":{"aliases":["Delete","Insert","Merge","ModifyTable","T_ModifyTable","Update"],"category":"Modification","content_hash":"68bbce37f45404930fee9ad5ae3daa94be8681a1f255e3a0e86f0d3d67324dcf","imported_at":"2026-09-30T00:40:44.164051+08:00","name":"ModifyTable","name_zh":"ModifyTable","slug":"modifytable","summary":"Performs the data-modification operation selected by the plan and produces RETURNING rows when requested."}},"Definition":{"Collection":"plan","Key":"modifytable","SourceDatabase":"center","Version":"18","SourceTable":"plan_node","SourceKey":"modifytable","SourceRevision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","Facts":{"comparison_data":{"initializer":"ExecInitModifyTable","memory_mechanism":"unclassified","node_tag":"T_ModifyTable","parallel_callbacks":[],"partial_modes":[],"strategies":[],"text_names":["Insert","Update","Delete","Merge"]},"comparison_hash":"cf664334c8d3479ccec4439895ce74d4602368021778f85473730f30aa4ff4db","description":["Performs the data-modification operation selected by the plan and produces RETURNING rows when requested."],"evidence_kind":"source and documentation","explain_names":["Insert","Update","Delete","Merge"],"explain_prefixes":["Parallel","Async"],"facts":[{"label":"Core node tag","value":"T_ModifyTable"},{"label":"Structured EXPLAIN Node Type","value":"ModifyTable"},{"label":"Inputs","value":"Modification input plan or plans"},{"label":"Output","value":"RETURNING tuples when requested"},{"label":"Executor initializer","value":"ExecInitModifyTable"},{"label":"Memory mechanism","value":"unclassified"}],"memory":{"description":"This extraction does not assign a universal memory limit or spill policy to this node. Inspect the same-build implementation and its expressions or provider.","evidence":[{"archive_sha256":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","label":"src/backend/executor/nodeModifyTable.c","path":"src/backend/executor/nodeModifyTable.c","sha256":"0fc3cb180b3443f216142954e43d8ed5f84713d75094ce8cd2785ad8f604bd68","url":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2"}],"mechanism":"unclassified","source_notes":["If the FDW supports batching, and batching is requested, accumulate rows and insert them in batches. Otherwise use the per-row inserts.","Initialize the batch slots. We don't know how many slots will be needed, so we initialize them as the batch grows, and we keep them across batches. To mitigate an inefficiency in how resource owner handles objects with many references (as with many slots all referencing the same tuple descriptor) we copy the appropriate tuple descriptor for each slot."]},"node_tag":"T_ModifyTable","parallel_callbacks":[],"partial_modes":[],"related":[{"label":"EXPLAIN","url":"/wiki/sql/explain/?v=18"},{"label":"Using EXPLAIN","url":"/docs/18/using-explain.html"},{"label":"Parallel plans","url":"/docs/18/parallel-plans.html"}],"release":{"channel":"stable","label":"18.6","major":"18","ref":"PostgreSQL 18.6 source archive","revision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","source_snapshot_utc":"","source_url":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2"},"runtime_verified":false,"sections":[{"paragraphs":["Structured formats use the Node Type above. Text-format spellings can also include operation, strategy, join type, scan direction or aggregation-stage attributes.","Text names recorded by this source: Insert, Update, Delete, Merge.","Parallel-aware and parallel-safe are different plan properties. A node running inside a parallel worker is not necessarily a parallel-aware node."],"title":"EXPLAIN names and attributes"},{"paragraphs":["This extraction does not assign a universal memory limit or spill policy to this node. Inspect the same-build implementation and its expressions or provider.","If the FDW supports batching, and batching is requested, accumulate rows and insert them in batches. Otherwise use the per-row inserts.","Initialize the batch slots. We don't know how many slots will be needed, so we initialize them as the batch grows, and we keep them across batches. To mitigate an inefficiency in how resource owner handles objects with many references (as with many slots all referencing the same tuple descriptor) we copy the appropriate tuple descriptor for each slot."],"title":"Memory and temporary storage"},{"paragraphs":["The source callbacks below can coordinate execution or collect worker instrumentation. Their presence is not a blanket claim that this node supports a shared parallel scan or shared state.","Callbacks in this build: none extracted from this node implementation."],"title":"Parallel execution and instrumentation"},{"paragraphs":["Merge join requires its input data to be sorted on the join keys. In this example each input is sorted by using an index scan to visit the rows in the correct order; but a sequential scan and sort could also be used. (Sequential-scan-and-sort frequently beats an index scan for sorting many rows, because of the nonsequential disk access required by the index scan.)","One way to look at variant plans is to force the planner to disregard whatever strategy it thought was the cheapest, using the enable/disable flags described in Section 19.7.1 . (This is a crude tool, but useful. See also Section 14.3 .) For example, if we're unconvinced that merge join is the best join type for the previous example, we could try","which shows that the planner thinks that hash join would be nearly 50% more expensive than merge join for this case. Of course, the next question is whether it's right about that. We can investigate that using EXPLAIN ANALYZE , as discussed below .","As seen in this example, when the query is an INSERT , UPDATE , DELETE , or MERGE command, the actual work of applying the table changes is done by a top-level Insert, Update, Delete, or Merge plan node. The plan nodes underneath this node perform the work of locating the old rows and/or computing the new data. So above, we see the same sort of bitmap table scan we've seen already, and its output is fed to an Update node that stores the updated rows. It's worth noting that although the data-modifying node can take a considerable amount of run time (here, it's consuming the lion's share of the time), the planner does not currently add anything to the cost estimates to account for that work. That's because the work to be done is the same for every correct query plan, so it doesn't affect planning decisions.","When an UPDATE , DELETE , or MERGE command affects a partitioned table or inheritance hierarchy, the output might look like this:","In this example the Update node needs to consider three child tables, but not the originally-mentioned partitioned table (since that never stores any data). So there are three input scanning subplans, one per table. For clarity, the Update node is annotated to show the specific target tables that will be updated, in the same order as the corresponding subplans."],"title":"Same-version manual discussion"},{"blocks":[{"code":"EXPLAIN SELECT *\nFROM tenk1 t1, onek t2\nWHERE t1.unique1 \u003c 100 AND t1.unique2 = t2.unique2;\n\n                                        QUERY PLAN\n------------------------------------------------------------------------------------------\n Merge Join  (cost=0.56..233.49 rows=10 width=488)\n   Merge Cond: (t1.unique2 = t2.unique2)\n   -\u003e  Index Scan using tenk1_unique2 on tenk1 t1  (cost=0.29..643.28 rows=100 width=244)\n         Filter: (unique1 \u003c 100)\n   -\u003e  Index Scan using onek_unique2 on onek t2  (cost=0.28..166.28 rows=1000 width=244)","paragraphs":["Example copied from the PostgreSQL 18.6 manual; it was not executed for this collection.","Another possible type of join is a merge join, illustrated here:"],"source":{"label":"PostgreSQL 18.6 · using-explain","path":"using-explain.html","sha256":"60040c30180093418a0affe56dd27dff9df2504b705b38039589e458bf5c31ed","url":"/docs/18/using-explain.html#USING-EXPLAIN-BASICS"}},{"code":"BEGIN;\n\nEXPLAIN ANALYZE UPDATE tenk1 SET hundred = hundred + 1 WHERE unique1 \u003c 100;\n\n                                                           QUERY PLAN\n--------------------------------------------------------------------------------------------------------------------------------\n Update on tenk1  (cost=5.06..225.23 rows=0 width=0) (actual time=1.634..1.635 rows=0.00 loops=1)\n   -\u003e  Bitmap Heap Scan on tenk1  (cost=5.06..225.23 rows=100 width=10) (actual time=0.065..0.141 rows=100.00 loops=1)\n         Recheck Cond: (unique1 \u003c 100)\n         Heap Blocks: exact=90\n         Buffers: shared hit=4 read=2\n         -\u003e  Bitmap Index Scan on tenk1_unique1  (cost=0.00..5.04 rows=100 width=0) (actual time=0.031..0.031 rows=100.00 loops=1)\n               Index Cond: (unique1 \u003c 100)\n               Index Searches: 1\n               Buffers: shared read=2\n Planning Time: 0.151 ms\n Execution Time: 1.856 ms\n\nROLLBACK;","paragraphs":["Example copied from the PostgreSQL 18.6 manual; it was not executed for this collection.","Keep in mind that because EXPLAIN ANALYZE actually runs the query, any side-effects will happen as usual, even though whatever results the query might output are discarded in favor of printing the EXPLAIN data. If you want to analyze a data-modifying query without changing your tables, you can roll the command back afterwards, for example:"],"source":{"label":"PostgreSQL 18.6 · using-explain","path":"using-explain.html","sha256":"60040c30180093418a0affe56dd27dff9df2504b705b38039589e458bf5c31ed","url":"/docs/18/using-explain.html#USING-EXPLAIN-ANALYZE"}}],"title":"Examples from this manual build"},{"paragraphs":["NOTES The ModifyTable node receives input from its outerPlan, which is the data to insert for INSERT cases, the changed columns' new values plus row-locating info for UPDATE and MERGE cases, or just the row-locating info for DELETE cases.","The relation to modify can be an ordinary table, a foreign table, or a view. If it's a view, either it has sufficient INSTEAD OF triggers or this node executes only MERGE ... DO NOTHING. If the original MERGE targeted a view not in one of those two categories, earlier processing already pointed the ModifyTable result relation to an underlying relation of that other view. This node does process ri_WithCheckOptions, which may have expressions from those other, automatically updatable views.","MERGE runs a join between the source relation and the target table. If any WHEN NOT MATCHED [BY TARGET] clauses are present, then the join is an outer join that might output tuples without a matching target tuple. In this case, any unmatched target tuples will have NULL row-locating info, and only INSERT can be run. But for matched target tuples, the row-locating info is used to determine the tuple to UPDATE or DELETE. When all clauses are WHEN MATCHED or WHEN NOT MATCHED BY SOURCE, all tuples produced by the join will include a matching target tuple, so all tuples contain row-locating info.","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, we just loop within the node until all the work is done, then return NULL. This avoids useless call/return overhead.","Context struct for a ModifyTable operation, containing basic execution state and some output variables populated by ExecUpdateAct() and ExecDeleteAct() to report the result of their actions to callers."],"title":"Executor implementation notes"},{"code":"case T_ModifyTable:\n\t\t\tsname = \"ModifyTable\";\n\t\t\tswitch (((ModifyTable *) plan)-\u003eoperation)\n\t\t\t{\n\t\t\t\tcase CMD_INSERT:\n\t\t\t\t\tpname = operation = \"Insert\";\n\t\t\t\t\tbreak;\n\t\t\t\tcase CMD_UPDATE:\n\t\t\t\t\tpname = operation = \"Update\";\n\t\t\t\t\tbreak;\n\t\t\t\tcase CMD_DELETE:\n\t\t\t\t\tpname = operation = \"Delete\";\n\t\t\t\t\tbreak;\n\t\t\t\tcase CMD_MERGE:\n\t\t\t\t\tpname = operation = \"Merge\";\n\t\t\t\t\tbreak;\n\t\t\t\tdefault:\n\t\t\t\t\tpname = \"???\";\n\t\t\t\t\tbreak;\n\t\t\t}\n\t\t\tbreak;","title":"EXPLAIN identity in core source"}],"source_inventory":{"executor":"src/backend/executor/execProcnode.c","explain":"src/backend/commands/explain.c","implementation":"src/backend/executor/nodeModifyTable.c"},"sources":[{"archive_sha256":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","label":"src/backend/commands/explain.c:1385","line":1385,"path":"src/backend/commands/explain.c","sha256":"34c86d6070224a0e981efef51f79101d6d505e5874f1684ace183034bab14bb4","url":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2"},{"archive_sha256":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","label":"src/backend/executor/execProcnode.c:176","line":176,"path":"src/backend/executor/execProcnode.c","sha256":"f8a06a3f539077249b20664b2812433db6d7bd12b2c0ca633525db43d06f112a","url":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2"},{"archive_sha256":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","label":"src/backend/executor/nodeModifyTable.c","path":"src/backend/executor/nodeModifyTable.c","sha256":"0fc3cb180b3443f216142954e43d8ed5f84713d75094ce8cd2785ad8f604bd68","url":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2"},{"archive_sha256":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","label":"src/include/nodes/plannodes.h","path":"src/include/nodes/plannodes.h","sha256":"52422b327a8049fbbb20d8b96008a0fc0a6fafa60f7eff3c695d5b2e83830120","url":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2"},{"label":"PostgreSQL 18.6 · using-explain","path":"using-explain.html","sha256":"60040c30180093418a0affe56dd27dff9df2504b705b38039589e458bf5c31ed","url":"/docs/18/using-explain.html#USING-EXPLAIN-BASICS"},{"label":"PostgreSQL 18.6 · using-explain","path":"using-explain.html","sha256":"60040c30180093418a0affe56dd27dff9df2504b705b38039589e458bf5c31ed","url":"/docs/18/using-explain.html#USING-EXPLAIN-ANALYZE"}],"strategies":[],"tables":[{"columns":[{"key":"label","label":"Text-format label"},{"key":"identity","label":"Structured node identity"}],"key":"explain-labels","rows":[{"identity":"ModifyTable","label":"Insert"},{"identity":"ModifyTable","label":"Update"},{"identity":"ModifyTable","label":"Delete"},{"identity":"ModifyTable","label":"Merge"}],"title":"EXPLAIN labels in this source build"}]},"ManualEvidence":{"release":{"channel":"stable","label":"18.6","major":"18","ref":"PostgreSQL 18.6 source archive","revision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","source_snapshot_utc":"","source_url":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2"},"sources":[{"archive_sha256":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","label":"src/backend/commands/explain.c:1385","line":1385,"path":"src/backend/commands/explain.c","sha256":"34c86d6070224a0e981efef51f79101d6d505e5874f1684ace183034bab14bb4","url":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2"},{"archive_sha256":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","label":"src/backend/executor/execProcnode.c:176","line":176,"path":"src/backend/executor/execProcnode.c","sha256":"f8a06a3f539077249b20664b2812433db6d7bd12b2c0ca633525db43d06f112a","url":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2"},{"archive_sha256":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","label":"src/backend/executor/nodeModifyTable.c","path":"src/backend/executor/nodeModifyTable.c","sha256":"0fc3cb180b3443f216142954e43d8ed5f84713d75094ce8cd2785ad8f604bd68","url":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2"},{"archive_sha256":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","label":"src/include/nodes/plannodes.h","path":"src/include/nodes/plannodes.h","sha256":"52422b327a8049fbbb20d8b96008a0fc0a6fafa60f7eff3c695d5b2e83830120","url":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2"},{"label":"PostgreSQL 18.6 · using-explain","path":"using-explain.html","sha256":"60040c30180093418a0affe56dd27dff9df2504b705b38039589e458bf5c31ed","url":"/docs/18/using-explain.html#USING-EXPLAIN-BASICS"},{"label":"PostgreSQL 18.6 · using-explain","path":"using-explain.html","sha256":"60040c30180093418a0affe56dd27dff9df2504b705b38039589e458bf5c31ed","url":"/docs/18/using-explain.html#USING-EXPLAIN-ANALYZE"}]},"MeasuredEvidence":{"runtime_verified":false}},"Text":{"Collection":"plan","Key":"modifytable","SourceDatabase":"center","Version":"18","Locale":"en","Title":"ModifyTable","Summary":"Performs the data-modification operation selected by the plan and produces RETURNING rows when requested.","BodyHTML":"\u003cp\u003ePerforms the data-modification operation selected by the plan and produces RETURNING rows when requested.\u003c/p\u003e","SourceRevision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","ContentHash":"c38ec8f15450571f4dc2d25178a2ce28e5b4d875001b14ca4ed21e93a0cd5d31","Payload":{"description":["Performs the data-modification operation selected by the plan and produces RETURNING rows when requested."],"related":[{"label":"EXPLAIN","url":"/wiki/sql/explain/?v=18"},{"label":"Using EXPLAIN","url":"/docs/18/using-explain.html"},{"label":"Parallel plans","url":"/docs/18/parallel-plans.html"}],"sections":[{"paragraphs":["Structured formats use the Node Type above. Text-format spellings can also include operation, strategy, join type, scan direction or aggregation-stage attributes.","Text names recorded by this source: Insert, Update, Delete, Merge.","Parallel-aware and parallel-safe are different plan properties. A node running inside a parallel worker is not necessarily a parallel-aware node."],"title":"EXPLAIN names and attributes"},{"paragraphs":["This extraction does not assign a universal memory limit or spill policy to this node. Inspect the same-build implementation and its expressions or provider.","If the FDW supports batching, and batching is requested, accumulate rows and insert them in batches. Otherwise use the per-row inserts.","Initialize the batch slots. We don't know how many slots will be needed, so we initialize them as the batch grows, and we keep them across batches. To mitigate an inefficiency in how resource owner handles objects with many references (as with many slots all referencing the same tuple descriptor) we copy the appropriate tuple descriptor for each slot."],"title":"Memory and temporary storage"},{"paragraphs":["The source callbacks below can coordinate execution or collect worker instrumentation. Their presence is not a blanket claim that this node supports a shared parallel scan or shared state.","Callbacks in this build: none extracted from this node implementation."],"title":"Parallel execution and instrumentation"},{"paragraphs":["Merge join requires its input data to be sorted on the join keys. In this example each input is sorted by using an index scan to visit the rows in the correct order; but a sequential scan and sort could also be used. (Sequential-scan-and-sort frequently beats an index scan for sorting many rows, because of the nonsequential disk access required by the index scan.)","One way to look at variant plans is to force the planner to disregard whatever strategy it thought was the cheapest, using the enable/disable flags described in Section 19.7.1 . (This is a crude tool, but useful. See also Section 14.3 .) For example, if we're unconvinced that merge join is the best join type for the previous example, we could try","which shows that the planner thinks that hash join would be nearly 50% more expensive than merge join for this case. Of course, the next question is whether it's right about that. We can investigate that using EXPLAIN ANALYZE , as discussed below .","As seen in this example, when the query is an INSERT , UPDATE , DELETE , or MERGE command, the actual work of applying the table changes is done by a top-level Insert, Update, Delete, or Merge plan node. The plan nodes underneath this node perform the work of locating the old rows and/or computing the new data. So above, we see the same sort of bitmap table scan we've seen already, and its output is fed to an Update node that stores the updated rows. It's worth noting that although the data-modifying node can take a considerable amount of run time (here, it's consuming the lion's share of the time), the planner does not currently add anything to the cost estimates to account for that work. That's because the work to be done is the same for every correct query plan, so it doesn't affect planning decisions.","When an UPDATE , DELETE , or MERGE command affects a partitioned table or inheritance hierarchy, the output might look like this:","In this example the Update node needs to consider three child tables, but not the originally-mentioned partitioned table (since that never stores any data). So there are three input scanning subplans, one per table. For clarity, the Update node is annotated to show the specific target tables that will be updated, in the same order as the corresponding subplans."],"title":"Same-version manual discussion"},{"blocks":[{"code":"EXPLAIN SELECT *\nFROM tenk1 t1, onek t2\nWHERE t1.unique1 \u003c 100 AND t1.unique2 = t2.unique2;\n\n                                        QUERY PLAN\n------------------------------------------------------------------------------------------\n Merge Join  (cost=0.56..233.49 rows=10 width=488)\n   Merge Cond: (t1.unique2 = t2.unique2)\n   -\u003e  Index Scan using tenk1_unique2 on tenk1 t1  (cost=0.29..643.28 rows=100 width=244)\n         Filter: (unique1 \u003c 100)\n   -\u003e  Index Scan using onek_unique2 on onek t2  (cost=0.28..166.28 rows=1000 width=244)","paragraphs":["Example copied from the PostgreSQL 18.6 manual; it was not executed for this collection.","Another possible type of join is a merge join, illustrated here:"],"source":{"label":"PostgreSQL 18.6 · using-explain","path":"using-explain.html","sha256":"60040c30180093418a0affe56dd27dff9df2504b705b38039589e458bf5c31ed","url":"/docs/18/using-explain.html#USING-EXPLAIN-BASICS"}},{"code":"BEGIN;\n\nEXPLAIN ANALYZE UPDATE tenk1 SET hundred = hundred + 1 WHERE unique1 \u003c 100;\n\n                                                           QUERY PLAN\n--------------------------------------------------------------------------------------------------------------------------------\n Update on tenk1  (cost=5.06..225.23 rows=0 width=0) (actual time=1.634..1.635 rows=0.00 loops=1)\n   -\u003e  Bitmap Heap Scan on tenk1  (cost=5.06..225.23 rows=100 width=10) (actual time=0.065..0.141 rows=100.00 loops=1)\n         Recheck Cond: (unique1 \u003c 100)\n         Heap Blocks: exact=90\n         Buffers: shared hit=4 read=2\n         -\u003e  Bitmap Index Scan on tenk1_unique1  (cost=0.00..5.04 rows=100 width=0) (actual time=0.031..0.031 rows=100.00 loops=1)\n               Index Cond: (unique1 \u003c 100)\n               Index Searches: 1\n               Buffers: shared read=2\n Planning Time: 0.151 ms\n Execution Time: 1.856 ms\n\nROLLBACK;","paragraphs":["Example copied from the PostgreSQL 18.6 manual; it was not executed for this collection.","Keep in mind that because EXPLAIN ANALYZE actually runs the query, any side-effects will happen as usual, even though whatever results the query might output are discarded in favor of printing the EXPLAIN data. If you want to analyze a data-modifying query without changing your tables, you can roll the command back afterwards, for example:"],"source":{"label":"PostgreSQL 18.6 · using-explain","path":"using-explain.html","sha256":"60040c30180093418a0affe56dd27dff9df2504b705b38039589e458bf5c31ed","url":"/docs/18/using-explain.html#USING-EXPLAIN-ANALYZE"}}],"title":"Examples from this manual build"},{"paragraphs":["NOTES The ModifyTable node receives input from its outerPlan, which is the data to insert for INSERT cases, the changed columns' new values plus row-locating info for UPDATE and MERGE cases, or just the row-locating info for DELETE cases.","The relation to modify can be an ordinary table, a foreign table, or a view. If it's a view, either it has sufficient INSTEAD OF triggers or this node executes only MERGE ... DO NOTHING. If the original MERGE targeted a view not in one of those two categories, earlier processing already pointed the ModifyTable result relation to an underlying relation of that other view. This node does process ri_WithCheckOptions, which may have expressions from those other, automatically updatable views.","MERGE runs a join between the source relation and the target table. If any WHEN NOT MATCHED [BY TARGET] clauses are present, then the join is an outer join that might output tuples without a matching target tuple. In this case, any unmatched target tuples will have NULL row-locating info, and only INSERT can be run. But for matched target tuples, the row-locating info is used to determine the tuple to UPDATE or DELETE. When all clauses are WHEN MATCHED or WHEN NOT MATCHED BY SOURCE, all tuples produced by the join will include a matching target tuple, so all tuples contain row-locating info.","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, we just loop within the node until all the work is done, then return NULL. This avoids useless call/return overhead.","Context struct for a ModifyTable operation, containing basic execution state and some output variables populated by ExecUpdateAct() and ExecDeleteAct() to report the result of their actions to callers."],"title":"Executor implementation notes"},{"code":"case T_ModifyTable:\n\t\t\tsname = \"ModifyTable\";\n\t\t\tswitch (((ModifyTable *) plan)-\u003eoperation)\n\t\t\t{\n\t\t\t\tcase CMD_INSERT:\n\t\t\t\t\tpname = operation = \"Insert\";\n\t\t\t\t\tbreak;\n\t\t\t\tcase CMD_UPDATE:\n\t\t\t\t\tpname = operation = \"Update\";\n\t\t\t\t\tbreak;\n\t\t\t\tcase CMD_DELETE:\n\t\t\t\t\tpname = operation = \"Delete\";\n\t\t\t\t\tbreak;\n\t\t\t\tcase CMD_MERGE:\n\t\t\t\t\tpname = operation = \"Merge\";\n\t\t\t\t\tbreak;\n\t\t\t\tdefault:\n\t\t\t\t\tpname = \"???\";\n\t\t\t\t\tbreak;\n\t\t\t}\n\t\t\tbreak;","title":"EXPLAIN identity in core source"}],"tables":[{"columns":[{"key":"label","label":"Text-format label"},{"key":"identity","label":"Structured node identity"}],"key":"explain-labels","rows":[{"identity":"ModifyTable","label":"Insert"},{"identity":"ModifyTable","label":"Update"},{"identity":"ModifyTable","label":"Delete"},{"identity":"ModifyTable","label":"Merge"}],"title":"EXPLAIN labels in this source build"}]}},"RequestedLocale":"zh-Hans","Fallback":true,"Versions":["10","11","12","13","14","15","16","17","18","19","20"],"Locales":["en"],"Signatures":null,"Spellings":null,"SQLState":null,"Evidence":null}