Re: "Value locking" Wiki page

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: Peter Geoghegan <pg(at)heroku(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: "Value locking" Wiki page
Date: 2014-10-02 03:53:17
Message-ID: 542CCC2D.2000006@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10/02/2014 03:06 AM, Peter Geoghegan wrote:
> In my view, it makes sense to fix that, and to make INSERT ... ON
> CONFLICT IGNORE work with exclusion constraints. However, it does not
> make sense to have INSERT ... ON CONFLICT UPDATE work with exclusion
> constraints. The user-visible semantics are very tricky, and I don't
> think it's useful.

If you were doing a multi-valued INSERT ... ON CONFLICT IGNORE and
wanted to do this with exclusion constraints, what would you do if the
insert its self contains values that can't exist in the table together?

Right now the whole insert will fail. Would that still be the case?
Would you insert one tuple then ignore the other? If so, what guarantee
if any would be made about which tuple would get inserted?

I think insert...ignore for exclusion constraints could be interesting,
but I'm not sure it's really the same as the upsert case. I guess I also
just don't really understand the utility of insert ... on conflict
ignore for GiST exclusion constraints.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2014-10-02 04:44:38 Re: UPSERT wiki page, and SQL MERGE syntax
Previous Message Craig Ringer 2014-10-02 03:25:15 Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept)