Re: Add ON CONFLICT DO RETURN clause

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Wolfgang Walther <walther(at)technowledgy(dot)de>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Add ON CONFLICT DO RETURN clause
Date: 2022-09-25 17:53:23
Message-ID: CAH2-WzkDnN7jDbT4waRZhnhsvk8pv74LP_ue2ow4LofKCNDZTQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Sep 25, 2022 at 8:55 AM Wolfgang Walther
<walther(at)technowledgy(dot)de> wrote:
> The attached patch adds a DO RETURN clause to be able to do this:
>
> INSERT INTO x (id) VALUES (1)
> ON CONFLICT DO RETURN
> RETURNING created_at;
>
> Much simpler. This will either insert or do nothing - but in both cases
> return a row.

How can you tell which it was, though?

I don't see why this statement should ever perform steps for any row
that are equivalent to DO NOTHING processing -- it should at least
lock each and every affected row, if only to conclusively determine
that there really must be a conflict.

In general ON CONFLICT DO UPDATE allows the user to add a WHERE clause
to back out of updating a row based on an arbitrary predicate. DO
NOTHING has no such WHERE clause. So DO NOTHING quite literally does
nothing for any rows that had conflicts, unlike DO UPDATE, which will
at the very least lock the row (with or without an explicit WHERE
clause).

The READ COMMITTED behavior for DO NOTHING is a bit iffy, even
compared to DO UPDATE, but the advantages in bulk loading scenarios
can be decisive. Or at least they were before we had MERGE.

--
Peter Geoghegan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message James Coleman 2022-09-25 19:28:32 Re: Allow foreign keys to reference a superset of unique columns
Previous Message Tom Lane 2022-09-25 16:19:54 Re: tweak to a few index tests to hits ambuildempty() routine.