On 2 November 2017 at 19:16, Peter Geoghegan <pg@bowt.ie> wrote:
> Simon Riggs <simon@2ndquadrant.com> wrote:
>>
>> So if I understand you correctly, in your view MERGE should just fail
>> with an ERROR if it runs concurrently with other DML?
>
>
> That's certainly my opinion on the matter. It seems like that might be
> the consensus, too.
Given that I only just found out what you've been talking about, I
don't believe that anybody else did either.
I think people imagined you had worked out how to make MERGE run
concurrently, I certainly did, but in fact you're just saying you
don't believe it ever should.
That is strange since the SQL Standard specifically allows the
implementation to decide upon concurrent behaviour.
> Without meaning to sound glib: we already did make it work for a
> special, restricted case that is important enough to justify introducing
> a couple of kludges -- ON CONFLICT DO UPDATE/upsert.
>
> I do agree that what I propose for MERGE will probably cause confusion;
> just look into Oracle's MERGE implementation for examples of this. We
> ought to go out of our way to make it clear that MERGE doesn't provide
> these guarantees.
So in your view we should make no attempt to avoid concurrent errors,
even when we have the capability to do so (in some cases) and doing so
would be perfectly compliant with the SQLStandard.
Yes, that certainly will make an easier patch for MERGE.
Or are you arguing against allowing any patch for MERGE?
Now we have more clarity, who else agrees with this?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
