Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0
От | Robert Haas |
---|---|
Тема | Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0 |
Дата | |
Msg-id | CA+TgmoayLYzJcKEz-ybBNfQ2kFdf30Wwk9a1Un_gV-Q7WXqtvQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0 (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: