On Wed, Nov 19, 2014 at 10:37 PM, Anssi Kääriäinen
<anssi.kaariainen@thl.fi> wrote:
> I think the biggest problem with the current approach is that there is
> no way to know if a row was skipped by the where clause when using
> INSERT ON CONFLICT UPDATE ... WHERE.
Well, there could have always been an UPDATE in a trigger or something
like that.
> I am a developer of the Django ORM. Django reports to the user whether a
> row was inserted or updated. It is possible to know which rows were
> inserted by returning the primary key value. If something is returned,
> then it was an insert. If Django implements updated vs inserted checking
> this way, then if PostgreSQL adds RETURNING for update case later on,
> that would be a breaking change for Django.
How does that actually work at the moment? Do you use RETURNING, or
look at the command tag? Would you be happy to just know that certain
rows were either inserted or updated in the context of an UPSERT (and
not cancelled by a BEFORE ROW INSERT or UPDATE trigger returning
NULL), or do you want to specifically know if there was an insert or
an update in respect of each row/slot processed?
--
Peter Geoghegan
