Re: [PATCH] Make ON CONFLICT DO NOTHING and ON CONFLICT DO UPDATE consistent
От | Andres Freund |
---|---|
Тема | Re: [PATCH] Make ON CONFLICT DO NOTHING and ON CONFLICT DO UPDATE consistent |
Дата | |
Msg-id | 20230207182725.7c562jksbwel3wlf@awork3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [PATCH] Make ON CONFLICT DO NOTHING and ON CONFLICT DO UPDATE consistent (Aleksander Alekseev <aleksander@timescale.com>) |
Ответы |
Re: [PATCH] Make ON CONFLICT DO NOTHING and ON CONFLICT DO UPDATE consistent
|
Список | pgsql-hackers |
Hi, On 2023-01-26 13:07:08 +0300, Aleksander Alekseev wrote: > > It *certainly* can't be right to just continue with the update in heap_update, > > I see no reason why. What makes this case so different from updating a > tuple created by the previous command? To me it's a pretty fundamental violation of how heap visibility works. I'm quite sure that there will be problems, but I don't feel like investing the time to find a reproducer for something that I'm ready to reject on principle. > > as you've done. You'd have to skip the update, not execute it. What am I > > missing here? > > Simply skipping updates in a statement that literally says DO UPDATE > doesn't seem to be the behavior a user would expect. Given that we skip the update in "UPDATE", your argument doesn't hold much water. > > I think this'd completely break triggers, for example, because they won't be > > able to get the prior row version, since it won't actually be a row ever > > visible (due to cmin=cmax). > > > > I suspect it might break unique constraints as well, because we'd end up with > > an invisible row in part of the ctid chain. > > That's a reasonable concern, however I was unable to break unique > constraints or triggers so far: I think you'd have to do a careful analysis of a lot of code for that to hold any water. I continue to think that we should just reject this behavioural change. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: