Re: [HACKERS] MERGE SQL Statement for PG11 - Mailing list pgsql-hackers

From Geoff Winkless
Subject Re: [HACKERS] MERGE SQL Statement for PG11
Date
Msg-id CAEzk6fdDEniFnJE5Oi_vFGMZychLZTNgo-uoGQfDauPCbLzu1Q@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] MERGE SQL Statement for PG11  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
On 6 November 2017 at 17:35, Simon Riggs <simon@2ndquadrant.com> wrote:
> I read that step 3 in Approach2 is some kind of problem in MVCC
> semantics. My understanding is that SQL Standard allows us to define
> what the semantics of the statement are in relation to concurrency, so
> any semantic issue can be handled by defining it to work the way we
> want. The semantics are:
> a) when a unique index is available we avoid errors by using semantics
> of INSERT .. ON CONFLICT UPDATE.
> b) when a unique index is not available we use other semantics.

I'm obviously being obtuse.

If a unique index is not available, then surely there won't _be_ a
failure? The INSERT (or indeed UPDATE) that results in two similar
records will simply happen, and you will end up with two records the
same. That's OK, based on the semantics of MERGE, no? At the
transaction-start INSERT was the correct thing to do.

Geoff


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: [HACKERS] Exclude pg_internal.init from base backup
Next
From: David Steele
Date:
Subject: Re: [HACKERS] Exclude pg_internal.init from base backup