On Wed, 24 Oct 2001, Tom Lane wrote: > The only reason we do this is to enforce the "triggered data change > violation" restriction of the spec. However, I think we've > misinterpreted the spec. The code prevents an RI referenced value from > being changed more than once in a transaction, but what the spec > actually says is thou shalt not change it more than once per > *statement*. We have discussed this several times in the past and > I think people have agreed that the current behavior is wrong, > but nothing's been done about it. > > I think all we need to do to implement things correctly is to consider a > previous event only if both xmin and cmin of the old tuple match the > current xact & command IDs, rather than considering it on the basis of > xmin alone.
Are there any things that might update the command ID during the execution of the statement from inside functions that are being run? I really don't understand the details of how that works (which is the biggest reason I haven't yet tackled some of the big remaining broken stuff in the referential actions, because AFAICT we need to be able to update a row that matched at the beginning of the statement, not the ones that match at the time the triggers run). ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])