Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Date
Msg-id 54803FC2.9020903@2ndquadrant.com
Whole thread Raw
In response to Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}  (Anssi Kääriäinen <anssi.kaariainen@thl.fi>)
Responses Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}  (Peter Geoghegan <pg@heroku.com>)
List pgsql-hackers
On 12/04/2014 07:07 PM, Anssi Kääriäinen wrote:
> On Wed, 2014-11-26 at 16:59 -0800, Peter Geoghegan wrote:
>> On Mon, Nov 24, 2014 at 1:03 PM, Peter Geoghegan <pg@heroku.com> wrote:
>>> Looks like the consensus is that we should have RETURNING project
>>> updated tuples too, then.
>>
>> Attached revision, v1.5, establishes this behavior (as always, there
>> is a variant for each approach to value locking). There is a new
>> commit with a commit message describing the new RETURNING/command tag
>> behavior in detail, so no need to repeat it here. The documentation
>> has been updated in these areas, too.
> 
> It seems there isn't any way to distinguish between insert and update of
> given row. Maybe a pseudo-column can be added so that it can be used in
> the returning statement

Yes, I think that's pretty important. With a negative attno so it's
treated as a "hidden" col that must be explicitly named to be shown and
won't be confused with user columns.


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



pgsql-hackers by date:

Previous
From: Anssi Kääriäinen
Date:
Subject: Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Next
From: Petr Jelinek
Date:
Subject: Re: [COMMITTERS] pgsql: Keep track of transaction commit timestamps