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