O Tom Lane έγραψε στις Feb 24, 2006 :
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > Tom Lane wrote:
> >> Achilleus Mantzios <achill@matrix.gatewaynet.com> writes:
> >>> Is there a reason that the NEW values should remain unchanged in AFTER
> >>> row triggers?
> >>
> >> By definition, an AFTER trigger is too late to change what was stored.
> >> Use a BEFORE trigger.
>
> > But a BEFORE trigger would alter the stored tuple, which is not what
> > Achilleus wants AFAIU.
>
> Oh, I misunderstood what he wanted ... and now that I do understand,
> I think it's a really terrible idea :-(. A large part of the point
> of using an AFTER trigger is to be certain you know exactly what got
> stored. (BEFORE triggers can never know this with certainty because
> there might be another BEFORE trigger that runs after them and edits the
> tuple some more.) If one AFTER trigger could falsify the data seen by
> the next, then that guarantee crumbles. For instance, a minor
> programming error in a user-written trigger could break foreign-key
> checking. No thanks.
Alvaro, Tom,
thanx a lot,
i'll have to incorporate that into dbmirror.
>
> > I think the desired effect can be had by having DBMirror check the
> > source relation of the inserted tuple (There is a hidden attributa
> > called tableoid IIRC that can be used for that, I think).
>
> I agree --- the correct solution is to change the DBMirror triggers to
> incorporate the desired filtering logic.
>
> regards, tom lane
>
--
-Achilleus
