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

From Peter Geoghegan
Subject Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Date
Msg-id CAM3SWZRvjyu8nnvw_JHeXx4YMQ9XaA7u0GEtLbCgym0oEAn_7Q@mail.gmail.com
Whole thread Raw
In response to Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}  (Peter Geoghegan <pg@heroku.com>)
Responses Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Mon, Dec 8, 2014 at 8:16 PM, Peter Geoghegan <pg@heroku.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.
-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: inherit support for foreign tables
Next
From: Josh Berkus
Date:
Subject: Re: 9.5 release scheduling (was Re: logical column ordering)