On Mon, Mar 7, 2022, at 4:59 PM, Álvaro Herrera wrote:
I attach v13 here. This version includes a 0002 that's does the split of nodeModifyTable.c routines, then 0003 implements MERGE on top of that. 0001 is as before.
In 0002, I've opted to have two separate structs. One is the ModifyTableContext, as before, but I've removed 'tupleid' and 'oldtuple' (the specification of the tuple to delete/update) because it makes ExecCrossPartitionUpdate cleaner if we pass them separately. The second struct is UpdateContext, which is used inside ExecUpdate as output data from its subroutines. This is also for the benefit of cross-partition updates.
I'm pretty happy with how this turned out; even without considering MERGE, it seems to me that ExecUpdate benefits from being shorter.
Hi,
For v13-0003-MERGE-SQL-Command-following-SQL-2016.patch :
+ * Reset per-tuple memory context to free any expression evaluation + * storage allocated in the previous cycle. + */
+ ResetExprContext(econtext);
Why is the memory cleanup done in the next cycle ? Can the cleanup be done at the end of the current cycle ?
+ * XXX Should this explain why MERGE has the same logic as UPDATE?