Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}

From: Marti Raudsepp <marti(at)juffo(dot)org>
To: Peter Geoghegan <pg(at)heroku(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Craig Ringer <craig(at)2ndquadrant(dot)com>
Subject: Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Date: 2014-10-08 09:33:25
Message-ID: CABRT9RDxxKRoJ=B2X2OJKWQL_EGcMKXSHaLTch3c6ArF4dbc2g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 7, 2014 at 2:27 PM, Marti Raudsepp <marti(at)juffo(dot)org> wrote:
> but the new approach seems
> surprising: changes from BEFORE INSERT get persisted in the database,
> but AFTER INSERT is not fired.

I am sorry, I realize now that I misunderstood the current proposed
trigger behavior, I thought what Simon Riggs wrote here already
happens:
https://groups.google.com/forum/#!msg/django-developers/hdzkoLYVjBY/bnXyBVqx95EJ

But the point still stands: firing INSERT triggers when the UPDATE
path is taken is counterintuitive. If we prevent changes of upsert
key columns in BEFORE triggers then we get the benefits, including
more straightforward trigger behavior and avoid problems with serial
columns.

Regards,
Marti

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2014-10-08 09:54:00 Re: BUG: *FF WALs under 9.2 (WAS: .ready files appearing on slaves)
Previous Message Peter Geoghegan 2014-10-08 09:28:46 Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}