Re: MERGE Specification

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Decibel! <decibel(at)decibel(dot)org>
Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>, Gregory Stark <stark(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, "A(dot)M(dot)" <agentm(at)themactionfaction(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: MERGE Specification
Date: 2008-04-24 16:19:28
Message-ID: 29957.1209053968@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Decibel! <decibel(at)decibel(dot)org> writes:
> 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.

Agreed. It seems to me that in the last set of discussions, we rejected
implementing MERGE precisely because it failed to provide a solution to
the race-condition problem. I'm not satisfied with a version that
doesn't handle that, because I think that is *exactly* what most people
will try to use it for. The non-concurrent bulk update case that Simon
is arguing for is the uncommon usage.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark 2008-04-24 16:20:46 Re: Proposed patch - psql wraps at window width
Previous Message Bruce Momjian 2008-04-24 16:11:30 Re: Is this TODO item done?