Re: support for MERGE
Alvaro Herrera <alvherre@alvh.no-ip.org>
From: Álvaro Herrera <alvherre@alvh.no-ip.org>
To: "Andres Freund" <andres@anarazel.de>
Cc: "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>,
"Simon Riggs" <simon.riggs@enterprisedb.com>,
"Tomas Vondra" <tomas.vondra@enterprisedb.com>,
"Zhihong Yu" <zyu@yugabyte.com>, "Daniel Westermann" <dwe@dbi-services.com>,
"Amit Langote" <amitlangote09@gmail.com>,
"Justin Pryzby" <pryzby@telsasoft.com>, "Japin Li" <japinli@hotmail.com>,
"Erik Rijkers" <er@xs4all.nl>,
"Jaime Casanova" <jcasanov@systemguards.com.ec>
Date: 2022-03-07T20:04:01Z
Lists: pgsql-hackers
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.
Commits
-
Doc fixes for MERGE statement
- 5dcebd10baa8 16.0 landed
- 5bb88967ed5c 15.0 landed
-
MERGE docs adjustments
- d6d1fbf353d1 15.0 landed
- 3d895bc846f2 16.0 landed
-
Link to MVCC docs in MERGE docs
- ffffeebf2447 15.0 landed
-
Fix EXPLAIN MERGE output when no tuples are processed
- 12e423e21d8e 15.0 landed
-
Make EXPLAIN MERGE output format more compact
- 598ac10be1c2 15.0 landed
-
Add support for MERGE SQL command
- 7103ebb7aae8 15.0 landed
-
Split ExecUpdate and ExecDelete into reusable pieces
- 25e777cf8e54 15.0 landed
-
Add API of sorts for transition table handling in trigger.c
- 3a46a45f6f00 15.0 landed
-
Represent Lists as expansible arrays, not chains of cons-cells.
- 1cff1b95ab6d 13.0 cited