Re: [HACKERS] MERGE SQL Statement for PG11 - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: [HACKERS] MERGE SQL Statement for PG11
Date
Msg-id CANP8+jJwsoa_ys3urjBh2-fMXTcxkfYT8NwEQPMuuZBkzcV=5A@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] MERGE SQL Statement for PG11  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] MERGE SQL Statement for PG11
List pgsql-hackers
On 4 January 2018 at 17:29, Robert Haas <robertmhaas@gmail.com> wrote:
> On Sat, Dec 30, 2017 at 6:01 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> Patch uses mechanism as agreed previously with Peter G et al. on this thread.
>
> I'm not sure that an agreement was reached, or what the substance of
> that agreement was.

I refer to this... and confirm I have implemented option 3

On 3 November 2017 at 11:07, Stephen Frost <sfrost@snowman.net> wrote:
> * 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.

-- 
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] MERGE SQL Statement for PG11
Next
From: Robert Haas
Date:
Subject: Re: Condition variable live lock