On Thursday 24 April 2008 12:19, Tom Lane wrote: > Decibel! <[EMAIL PROTECTED]> writes: > > That really strikes me as taking the "MySQL route". If push comes to > > shove, I'll take a MERGE with race conditions over no merge at all, > > but I think it's very important that it does the right thing. Just > > because the spec doesn't say anything about it doesn't mean it's ok. > > Agreed. It seems to me that in the last set of discussions, we rejected > implementing MERGE precisely because it failed to provide a solution to > the race-condition problem. I'm not satisfied with a version that > doesn't handle that, because I think that is *exactly* what most people > will try to use it for. The non-concurrent bulk update case that Simon > is arguing for is the uncommon usage. >
Perhaps a better option would be to implement Merge per spec, and then implement a "replace into" command for the oltp scenario. This way you keep the spec behavior for the spec syntax, and have a clearly non-spec command for non-spec behavior. -- Robert Treat Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers