On Fri, May 1, 2015 at 10:49 AM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
