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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Geoghegan <pg(at)heroku(dot)com>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Anssi Kääriäinen <anssi(dot)kaariainen(at)thl(dot)fi>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, 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>
Subject: Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Date: 2014-12-11 21:39:03
Message-ID: CA+TgmoZAVXMwOeBPK4ASZonuwUr3QPSWWk6XetXMcA+8H7Cd8Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Dec 11, 2014 at 1:11 AM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> On Mon, Dec 8, 2014 at 8:16 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
>> Attached revision, v1.6, slightly tweaks the ordering of per-statement
>> trigger execution.
>
> Right now, there is no way for a before row insert/update trigger to
> determine whether it was called as part of an INSERT ... ON CONFLICT
> UPDATE or not. It's also not possible for a DO INSTEAD trigger on a
> view (a before row insert trigger) to determine that it was called
> specifically due to an INSERT...IGNORE (which I think ought to imply
> that any corresponding, "redirected" insertion into a table should
> also use IGNORE....that's at least going to be something that a
> certain number of apps will need to be made robust against).
>
> The question is: Do we want to expose this distinction to triggers?
> The natural way to do so would probably be to add TG_SPECULATIVE
> special variable to plpgsql (and equivalent variables in other PLs).
> This text variable would be either "UPSERT" or "IGNORE"; it would be
> NULL when it was not applicable (e.g. with traditional INSERTs).
>
> How do people feel about this? Is it important to include this in our
> initial cut of the feature? I thought that I'd avoid that kind of
> thing until prompted to address it by others, since it probably won't
> end up being a common concern, but I'd like to hear a few opinions.

It's probably something we should add, but there's enough to do
getting the basic feature working first.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2014-12-11 21:40:16 Re: Commitfest problems
Previous Message David Johnston 2014-12-11 21:34:47 Re: 9.5 release scheduling (was Re: logical column ordering)