| From: | Andreas Karlsson <andreas(at)proxel(dot)se> |
|---|---|
| To: | Peter Geoghegan <pg(at)heroku(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, Kevin Grittner <kgrittn(at)ymail(dot)com>, Andres Freund <andres(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-11-20 01:37:55 |
| Message-ID: | 546D45F3.10802@proxel.se |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 11/20/2014 01:52 AM, Peter Geoghegan wrote:
> On Mon, Nov 10, 2014 at 3:33 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> Also, I think someone else mentioned this a few months back.
Yeah, that was me.
I think we have three options.
1. Return only inserted tuples
2. Return inserted and updated tuples
3. Return inserted, updated and skipped tuples
To me option 1 is surprising and less useful since I imagine in most
cases where you do an upsert you do not care if the tuple was inserted
or updated as long as it has the right values after the upsert, and
these values is also what I would expect to be returned.
The possible use case I see for option 3 is when you want the values of
automatically generated columns but there is actually no work to do if
another transaction had already inserted the same row (same according to
the unique constraints). But this behavior even though useful in certain
cases might be surprising.
Andreas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2014-11-20 02:04:18 | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} |
| Previous Message | Michael Paquier | 2014-11-20 01:25:30 | Re: New Event Trigger: table_rewrite |