From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Craig Ringer <craig(at)2ndquadrant(dot)com> |
Subject: | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} |
Date: | 2014-09-03 21:13:00 |
Message-ID: | CAM3SWZQ-U6LDyw2dp1EE-jMaN2G1h=L0WG4mKtVPX6v4zdqfkg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Sep 3, 2014 at 9:51 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> INSERT INTO upsert(key, val) VALUES(1, 'insert') ON CONFLICT WITHIN
>> upsert_pkey UPDATE SET val = 'update';
>
> It seems to me that it would be better to specify a conflicting column
> set rather than a conflicting index name.
I'm open to pursuing that, provided there is a possible implementation
that's robust against things like BEFORE triggers that modify
constrained attributes. It must also work well with partial unique
indexes. So I imagine we'd have to determine a way of looking up the
unique index only after BEFORE triggers fire. Unless you're
comfortable with punting on some of these cases by throwing an error,
then all of this is actually surprisingly ticklish. You've already
expressed concerns about the feature not playing nice with existing,
peripheral features though.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Marko Tiikkaja | 2014-09-03 21:13:46 | Re: pgcrypto: PGP signatures |
Previous Message | Robert Haas | 2014-09-03 21:11:20 | Re: COPY and heap_sync |