Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Peter Geoghegan <pg@heroku.com>
From: Peter Geoghegan <pg@heroku.com>
To: Anssi Kääriäinen <anssi.kaariainen@thl.fi>
Cc: Craig Ringer <craig@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>
Date: 2014-12-05T20:04:01Z
Lists: pgsql-hackers
On Fri, Dec 5, 2014 at 1:01 AM, Anssi Kääriäinen <anssi.kaariainen@thl.fi> wrote: > If Django is going to use the INSERT ... ON CONFLICT UPDATE variant in > Django for the existing save() method, then it needs to know if the > result was an UPDATE or INSERT. If we are going to use this for other > operations (for example bulk merge of rows to the database), it would be > very convenient to have per-row updated/created information available so > that we can fire the post_save signals for the rows. If we don't have > that information available, it means we can't fire signals, and no > signals means we can't use the bulk merge operation internally as we > have to fire the signals where that happened before. > > Outside of Django there are likely similar reasons to want to know if > the result of an operation was a creation of a new row. The reason could > be creation of related row, doing some action in application layer, or > just UI message telling "object created successfully" vs "object updated > successfully". It probably isn't ideal, but you'd at least be able to do something with row level triggers in the absence of a standard way of directly telling if an insert or update was performed. -- Peter Geoghegan
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