On Fri, May 1, 2015 at 10:49 AM, Andres Freund <andres@anarazel.de> wrote:
>> One idea is to decide that an INSERT with an ON CONFLICT UPDATE
>> handler is still an INSERT. Period. So the INSERT triggers run, the
>> UPDATE triggers don't, and that's it.
>
> I think that'd be much worse.
OK. Well, in that case, I guess I'm inclined to think that we
shouldn't throw away the tuple the BEFORE trigger constructs.
> One question, that I was wondering about earlier, that also might
> influence this discussion, is what happens if you change the key we're
> using for resolution during either the BEFORE trigger or the ON CONFLICT
> ... SET. Right now the conflict will be on the version *after* the
> BEFORE INSERT, which I think think is the only reasonable option.
>
> And if you're mad enough to change the key in the ON CONFLICT ... SET
> ... you'll possibly get conflicts. I was, over IM, arguing for that to
> be forbidden to protect users against themselves, but Heikki said people
> might e.g. want to set a column in a key to NULL in that case.
I'm not a big fan of trying to protect users against themselves. I'm
fine with stupid user decisions resulting in errors.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company