On Sun, Oct 24, 2010 at 2:50 AM, Martijn van Oosterhout
> Can we please not get MERGE hung up on trying to make it atomic. The
> standard requires no such thing and there are plenty of uses of MERGE
> that don't involve high concurrency updates of the same row by
> different processes. If we want an atomic UPSERT, make that a seperate
> command, MERGE without atomicity is useful enough already.
Really? I don't really see any point in a non-atomic MERGE. Nor in a
non-atomic UPDATE or INSERT or any other operation. The A in ACID is
as important as any other letter.
For that matter if you don't care about atomicity then this is a
problem already solvable easily solvable in the application. Why
bother providing a special command for it. The whole reason to want a
special command is precisely because the database can implement it
atomically more easily and more efficiently than any application
Moreover having a case which is non-atomic and allows inconsistent
results or errors in the face of concurrent updates is a foot-gun.
Someone will come along and try to use it and it will appear to work
in their application but introduce nasty hidden race conditions.
In response to
pgsql-hackers by date
|Next:||From: Greg Stark||Date: 2010-10-24 23:16:56|
|Subject: Re: ask for review of MERGE|
|Previous:||From: Andrew Dunstan||Date: 2010-10-24 23:05:29|
|Subject: Re: why does plperl cache functions using just a bool for