Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Peter Geoghegan <pg@heroku.com>
Cc: Josh Berkus <josh@agliodbs.com>, Craig Ringer <craig@2ndquadrant.com>, Anssi Kääriäinen <anssi.kaariainen@thl.fi>, Simon Riggs <simon@2ndquadrant.com>, Bruce Momjian <bruce@momjian.us>, Kevin Grittner <kgrittn@ymail.com>, Andres Freund <andres@2ndquadrant.com>, Heikki Linnakangas <hlinnakangas@vmware.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2014-12-11T21:39:03Z
Lists: pgsql-hackers
On Thu, Dec 11, 2014 at 1:11 AM, Peter Geoghegan <pg@heroku.com> wrote: > 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. 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
Commits
-
Change the way we mark tuples as frozen.
- 37484ad2aace 9.4.0 cited
-
Add documentation for data-modifying statements in WITH clauses.
- 0ef0b3020402 9.1.0 cited