Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} 2.0 - Mailing list pgsql-hackers

From Geoff Winkless
Subject Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} 2.0
Date
Msg-id CAEzk6fdaHzGoGDbQe4cHfhu7MnKynaLd6e5C-_=drAcYYGkSdQ@mail.gmail.com
Whole thread Raw
In response to Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} 2.0  (Peter Geoghegan <pg@heroku.com>)
Responses Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} 2.0  (Geoff Winkless <pgsqladmin@geoff.dj>)
List pgsql-hackers
On 30 January 2015 at 21:58, Peter Geoghegan <pg@heroku.com> wrote:
> On Fri, Jan 30, 2015 at 6:59 AM, Geoff Winkless <pgsqladmin@geoff.dj> wrote:
>> I suppose there's no reason why we couldn't use a no-op ON CONFLICT
>> UPDATE anyway
>
> Right. IGNORE isn't really all that compelling for that reason. Note
> that this will still lock the unmodified row, though.

Mmmf. So I would have to make sure that my source tuples were unique
before doing the INSERT (otherwise the first ON CONFLICT UPDATE for a
tuple would block any other)? That's potentially very slow :(

When you say that you can't add exclusion constraints later, do you
mean from a coding point of view or just because people would get
confused whether exclusion constraints could be IGNOREd or not?

Geoff



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Redesigning checkpoint_segments
Next
From: Magnus Hagander
Date:
Subject: Re: Small doc patch about pg_service.conf