From: | Andreas Karlsson <andreas(at)proxel(dot)se> |
---|---|
To: | Peter Geoghegan <pg(at)heroku(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-08-28 19:13:01 |
Message-ID: | 53FF7F3D.4040407@proxel.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 08/28/2014 09:05 PM, Peter Geoghegan wrote:
> On Thu, Aug 28, 2014 at 7:29 AM, Andreas Karlsson <andreas(at)proxel(dot)se> wrote:
>> Personally I would find it surprising if RETURNING did not also return the
>> updated tuples. In many use cases for upsert the user does not care if the
>> row was new or not.
>
> I'm not attached to that particular behavior, but it does seem kind of
> similar to the behavior of BEFORE triggers, where a NULL return value
> ("do nothing") will also cause RETURNING to not project the tuple.
I see. So we have three cases where we may or may not want to project a
tuple.
1) The tuple was inserted
2) We got a conflict and updated the tuple
3) We got a conflict but skipped updating the tuple
My personal intuition was that (1) and (2) would be returned but not
(3). But I am not sure if that is the most useful behavior.
--
Andreas Karlsson
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2014-08-28 19:33:11 | Re: Per table autovacuum vacuum cost limit behaviour strange |
Previous Message | Peter Geoghegan | 2014-08-28 19:05:05 | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} |