Simon Riggs <si...@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
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?
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: