Greg Smith <g...@2ndquadrant.com> writes: > Marko Tiikkaja wrote: >> What's been bothering me is that so far there has not been an >> agreement on whether we need to protect against concurrency issues or >> not. In fact, there has been almost no discussion about the >> concurrency issues which AIUI have been the biggest single reason we >> don't have MERGE already.
> Sure there were, they just happened a long time ago. I tried to > summarize the previous discussion at > http://wiki.postgresql.org/wiki/SQL_MERGE with the following: > "PostgreSQL doesn't have a good way to lock access to a key value that > doesn't exist yet--what other databases call key range > locking...Improvements to the index implementation are needed to allow > this feature." This seems to be presuming there's a consensus that that's the way to implement it, which is news to me. Why wouldn't we try the INSERT first, and if we get a unique-key failure, do UPDATE instead? I am not at all in agreement that we ought to build key range locking, nor that it'd be particularly helpful for this problem even if we had it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
