Re: INSERT ... ON CONFLICT () SELECT

From: Matt Pulver <mpulver(at)unitytechgroup(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: INSERT ... ON CONFLICT () SELECT
Date: 2017-06-19 18:15:20
Message-ID: CAHiCE4Umo+D8YXa+MVcb2-AN2k1TMa=RPVZ4UpBOQn3+e=+ZJw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jun 18, 2017 at 9:21 PM, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:

> Returning rows with duplicate values seems rather unorthodox.
>

Ok, then option 2 it is.

In summary, this is what I am going to (attempt to) implement for the new
syntax:

INSERT ...
ON CONFLICT (...) DO SELECT
RETURNING ...

1. Rows that are in conflict are made available to the RETURNING clause.
In other words, it is like an idempotent "ON CONFLICT DO UPDATE".
2. Similarly, insertion sets that would cause the error "ON CONFLICT DO
UPDATE command cannot affect row a second time" if it were an "ON CONFLICT
DO UPDATE" statement will also cause a similar error for "ON CONFLICT DO
SELECT". This will prevent duplicate rows from being returned.
3. Like an "ON CONFLICT DO UPDATE", the returned rows cannot be changed
by another part of the wCTE, even if no actual insertions occurred.

Unless I have missed anything, I think all other issues have been
adequately addressed. Since there are no red lights, I shall proceed. :)

Best regards,
Matt

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message J Chapman Flack 2017-06-19 18:18:50 Re: Postgresql bug report - unexpected behavior of suppress_redundant_updates_trigger
Previous Message Shubham Barai 2017-06-19 17:30:23 Re: GSoC 2017 weekly progress reports (week 3)