Re: MERGE SQL Statement for PG11
Stephen Frost <sfrost@snowman.net>
From: Stephen Frost <sfrost@snowman.net>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Simon Riggs <simon@2ndquadrant.com>, Peter Geoghegan <pg@bowt.ie>, Michael Paquier <michael.paquier@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2017-11-03T11:07:25Z
Lists: pgsql-hackers
* Robert Haas (robertmhaas@gmail.com) wrote: > On Fri, Nov 3, 2017 at 1:05 PM, Simon Riggs <simon@2ndquadrant.com> wrote: > > We seem to have a few options for PG11 > > > > 1. Do nothing, we reject MERGE > > > > 2. Implement MERGE for unique index situations only, attempting to > > avoid errors (Simon OP) > > > > 3. Implement MERGE, but without attempting to avoid concurrent ERRORs (Peter) > > > > 4. Implement MERGE, while attempting to avoid concurrent ERRORs in > > cases where that is possible. > > > > Stephen, Robert, please say which option you now believe we should pick. > > I think Peter has made a good case for #3, so I lean toward that > option. I think #4 is too much of a non-obvious behavior difference > between the cases where we can avoid those errors and the cases where > we can't, and I don't see where #2 can go in the future other than #4. Agreed. Thanks! Stephen
Commits
-
Add support for MERGE SQL command
- 7103ebb7aae8 15.0 landed
-
Add API of sorts for transition table handling in trigger.c
- 3a46a45f6f00 15.0 landed
-
Revert MERGE patch
- 08ea7a2291db 11.0 cited
-
Fix several bugs related to ON CONFLICT's EXCLUDED pseudo relation.
- ad2278379244 9.6.0 cited