Re: After Trigger assignment to NEW

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