Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid

From: David Fetter <david(at)fetter(dot)org>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>, Boxuan Zhai <bxzhai2010(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid
Date: 2011-01-05 07:09:57
Message-ID: 20110105070957.GA7308@fetter.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message KaiGai Kohei 2011-01-05 08:25:19 Re: sepgsql contrib module
Previous Message Greg Smith 2011-01-05 06:55:02 Re: We need to log aborted autovacuums