Re: MERGE Specification - Mailing list pgsql-hackers

From Tom Lane
Subject Re: MERGE Specification
Date
Msg-id 29957.1209053968@sss.pgh.pa.us
Whole thread Raw
In response to Re: MERGE Specification  (Decibel! <decibel@decibel.org>)
Responses Re: MERGE Specification  (Simon Riggs <simon@2ndquadrant.com>)
Re: MERGE Specification  (Robert Treat <xzilla@users.sourceforge.net>)
List pgsql-hackers
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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Is this TODO item done?
Next
From: Simon Riggs
Date:
Subject: Re: Index AM change proposals, redux