| From: | Geoff Winkless <pgsqladmin(at)geoff(dot)dj> |
|---|---|
| To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, Robert Haas <robertmhaas(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: MERGE SQL Statement for PG11 |
| Date: | 2017-11-07 16:07:42 |
| Message-ID: | CAEzk6fdDEniFnJE5Oi_vFGMZychLZTNgo-uoGQfDauPCbLzu1Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 6 November 2017 at 17:35, Simon Riggs <simon(at)2ndquadrant(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Korotkov | 2017-11-07 16:24:27 | Re: Fwd: pg_trgm word_similarity inconsistencies or bug |
| Previous Message | Simon Riggs | 2017-11-07 16:03:53 | Re: Exclude pg_internal.init from base backup |