Re: MERGE Specification

Jim Nasby <decibel@decibel.org>

From: Decibel! <decibel@decibel.org>
To: Martijn van Oosterhout <kleptog@svana.org>
Cc: Gregory Stark <stark@enterprisedb.com>, Simon Riggs <simon@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>, "A.M." <agentm@themactionfaction.com>, pgsql-hackers@postgresql.org
Date: 2008-04-24T16:00:41Z
Lists: pgsql-hackers
On Apr 22, 2008, at 3:20 PM, Martijn van Oosterhout wrote:

> On Tue, Apr 22, 2008 at 02:19:24PM -0500, Decibel! wrote:
>> But no matter how this is done, I think we need to handle the race
>> conditions, and handle them by default. If people *really* know what
>> they're doing, they can disable the row locking (perhaps one way to
>> do this would be to grab an explicit lock on the table and have merge
>> check for that...).
>
> I disagree. The spec doesn't require it and MERGE is useful without  
> it.
> For a first cut I would say implement as the spec says, race  
> conditions
> and all. Later we can think on whether it's worth handling them
> directly.


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.
-- 
Decibel!, aka Jim C. Nasby, Database Architect  decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828