Re: [HACKERS] MERGE SQL Statement for PG11
От | Simon Riggs |
---|---|
Тема | Re: [HACKERS] MERGE SQL Statement for PG11 |
Дата | |
Msg-id | CANP8+jJwsoa_ys3urjBh2-fMXTcxkfYT8NwEQPMuuZBkzcV=5A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] MERGE SQL Statement for PG11 (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] MERGE SQL Statement for PG11
|
Список | 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 по дате отправления: