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