On Thursday 24 April 2008 12:19, Tom Lane wrote:
> Decibel! <decibel@decibel.org> 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
