Re: Remembering bug #6123
От | Kevin Grittner |
---|---|
Тема | Re: Remembering bug #6123 |
Дата | |
Msg-id | 4F0EAB0502000025000446F8@gw.wicourts.gov обсуждение исходный текст |
Ответ на | Re: Remembering bug #6123 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Remembering bug #6123
|
Список | pgsql-hackers |
Tom Lane <tgl@sss.pgh.pa.us> wrote: > I suggest that the current behavior was designed for the case of > independent concurrent updates, and you have not made a good > argument for changing that. What does make sense to me, in light > of these examples, is to complain if a BEFORE trigger modifies the > row "itself" (including indirect updates). IOW, at conclusion of > trigger firing (I see no need to do it for each trigger), check to > see if the target row has been outdated *by the current > transaction*, and throw error if not. > > And, if you accept the statement of the fix like that, then > actually there is no performance hit because there is no need to > introduce new tests. All we have to do is start treating > HeapTupleSelfUpdated result from heap_update or heap_delete as an > error case instead of an okay-do-nothing case. There doesn't even > need to be an explicit check that this was caused by a trigger, > because AFAICS there isn't any other possibility. I think that's pretty much what my previously posted patches did. Here's a slightly modified one, based on Florian's feedback. Is this what you had in mind, or am I misunderstanding? -Kevin
Вложения
В списке pgsql-hackers по дате отправления: