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
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} |