Horton

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

Alvaro Herrera <alvherre@2ndquadrant.com>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Peter Geoghegan <pg@heroku.com>
Cc: Petr Jelinek <petr@2ndquadrant.com>, 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>, Craig Ringer <craig@2ndquadrant.com>
Date: 2014-10-25T10:38:10Z
Lists: pgsql-hackers 
Peter Geoghegan wrote:
> On Fri, Oct 24, 2014 at 4:39 PM, Petr Jelinek <petr@2ndquadrant.com> wrote:

> > Ugh, you want to auto-magically detect what value is behind the EXCLUDED
> > based on how/where it's used in the UPDATE? That seems like quite a bad
> > idea.
> 
> That's *exactly* how DEFAULT works within UPDATE targetlists. There
> might be a few more details to work out here, but not terribly many,
> and that's going to be true no matter what. 95%+ of the time, it'll
> just be "val = EXCLUDED" anyway.

Petr's thought mirrors mine.  What are you going to do the other 5% of
the time?  Is there some other way to refer to the columns of the
"excluded" row?

-- 
Álvaro Herrera                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.