Re: [HACKERS] MERGE SQL Statement for PG11
От | Peter Geoghegan |
---|---|
Тема | Re: [HACKERS] MERGE SQL Statement for PG11 |
Дата | |
Msg-id | 20171103163539.GA17026@marmot обсуждение исходный текст |
Ответ на | Re: [HACKERS] MERGE SQL Statement for PG11 (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] MERGE SQL Statement for PG11
|
Список | pgsql-hackers |
Simon Riggs <simon@2ndquadrant.com> wrote: >>> The *only* behavioural difference I have proposed would be the *lack* >>> of an ERROR in (some) concurrent cases. >> >> I think that's a big difference. Error vs. non-error is a big deal by >> itself; > >Are you saying avoiding an ERROR is a bad or good thing? Are you really asking Robert to repeat what has already been said about a dozen different ways? That's *not* the only difference. You need to see a couple of steps ahead to see further differences, as the real dilemma comes when you have to reconcile having provided the UPSERT-guarantees with cases that that doesn't map on to (which can happen in a number of different ways). I don't understand why you'll talk about just about anything but that. This is a high-level concern about the overarching design. Do you really not understand the concern at this point? >> also, the non-error case involves departing from MVCC >> semantics just as INSERT .. ON CONFLICT UPDATE does. > >Meaning what exactly? What situation occurs that a user would be concerned with? > >Please describe exactly what you mean so we get it clear. > >The concurrent behaviour for MERGE is allowed to be >implementation-specific, so we can define it any way we want. Agreed -- we can. It isn't controversial at all to say that the SQL standard has nothing to say on this question. The problem is that the semantics you argue for are ill-defined, and seem to create more problems than they solve. Why keep bringing up the SQL standard? -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления: