From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, Kevin Grittner <kgrittn(at)ymail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Craig Ringer <craig(at)2ndquadrant(dot)com> |
Subject: | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} |
Date: | 2014-10-02 21:08:30 |
Message-ID: | CAM3SWZS0Q2qvRaFb9m1jP32L3WMs2s7BMybeKXRpG5MOUupy=A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Oct 2, 2014 at 1:10 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> I think if we use the MERGE command for this feature we would need to
> use a non-standard keyword to specify that we want OLTP/UPSERT
> functionality. That would allow us to mostly use the MERGE standard
> syntax without having surprises about non-standard behavior. I am
> thinking of how CONCURRENTLY changes the behavior of some commands.
That would leave you without a real general syntax. It'd also make
having certain aspects of an UPSERT more explicit be a harder goal
(there is no conventional join involved here - everything goes through
a unique index). Adding the magic keyword would break certain other
parts of the statement, so you'd have exact rules for what worked
where. I see no advantage, and considerable disadvantages.
Note that I've documented a lot of this stuff here:
https://wiki.postgresql.org/wiki/UPSERT
Mapping the join thing onto which unique index you want to make the
UPSERT target is very messy. There are a lot of corner cases. It's
quite ticklish.
Please add to it if you think we've missed something.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2014-10-02 21:09:43 | Re: TAP test breakage on MacOS X |
Previous Message | Claudio Freire | 2014-10-02 21:08:16 | Re: DDL Damage Assessment |