Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid
David Fetter <david@fetter.org>
From: David Fetter <david@fetter.org>
To: Greg Smith <greg@2ndquadrant.com>
Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, Stephen Frost <sfrost@snowman.net>, Robert Haas <robertmhaas@gmail.com>, Simon Riggs <simon@2ndquadrant.com>, Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi>, Boxuan Zhai <bxzhai2010@gmail.com>, pgsql-hackers@postgresql.org
Date: 2011-01-05T07:09:57Z
Lists: pgsql-hackers
On Tue, Jan 04, 2011 at 09:27:10PM -0500, Greg Smith wrote: > David Fetter wrote: > >How about implementing an UPSERT command as "take the lock, do the > >merge?" That way, we'd have both the simplicity for the simpler cases > >and a way to relax consistency guarantees for those who would like to > >do so. > > Main argument against is that path leads to a permanent non-standard > wart to support forever, just to work around what should be a > short-term problem. And I'm not sure whether reducing the goals to > only this actually improves the ability to ship something in the > near term too much. I think I haven't communicated clearly what I'm suggesting, which is that we ship with both an UPSERT and a MERGE, the former being ugly, crude and simple, and the latter festooned with dire warnings about isolation levels and locking. If shipping with a "wart," as you term it, isn't acceptable, then I'd advocate for going with just MERGE and documenting it inside and out, including one or more clearly written UPSERT and/or REPLACE INTO recipes. Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate