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

  1. Change the way we mark tuples as frozen.

  2. Add documentation for data-modifying statements in WITH clauses.