Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}

Craig Ringer <craig@2ndquadrant.com>

From: Craig Ringer <craig@2ndquadrant.com>
To: Anssi Kääriäinen <anssi.kaariainen@thl.fi>, Peter Geoghegan <pg@heroku.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Simon Riggs <simon@2ndquadrant.com>, Bruce Momjian <bruce@momjian.us>, Josh Berkus <josh@agliodbs.com>, Kevin Grittner <kgrittn@ymail.com>, Andres Freund <andres@2ndquadrant.com>, Heikki Linnakangas <hlinnakangas@vmware.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2014-12-04T11:04:34Z
Lists: 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


Commits

  1. Change the way we mark tuples as frozen.

  2. Add documentation for data-modifying statements in WITH clauses.