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

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Peter Geoghegan <pg(at)heroku(dot)com>
Cc: Petr Jelinek <petr(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(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-10-25 10:38:10
Message-ID: 20141025103810.GN1791@alvin.alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Geoghegan wrote:
> On Fri, Oct 24, 2014 at 4:39 PM, Petr Jelinek <petr(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2014-10-25 11:01:21 Re: pg_background (and more parallelism infrastructure patches)
Previous Message Ali Akbar 2014-10-25 10:20:18 Re: Function array_agg(array)