To: Alvaro Herrera <alvherre@commandprompt.com>
cc: Achilleus Mantzios <achill@matrix.gatewaynet.com>,
 pgsql-sql@postgresql.org
Subject: Re: After Trigger assignment to NEW 
In-reply-to: <20060224171652.GD7696@surnet.cl> 
References: <Pine.LNX.4.44.0602241831280.19738-100000@matrix.gatewaynet.com>
	<3649.1140797162@sss.pgh.pa.us> <20060224171652.GD7696@surnet.cl>
Comments: In-reply-to Alvaro Herrera <alvherre@commandprompt.com>
	message dated "Fri, 24 Feb 2006 14:16:52 -0300"
Date: Fri, 24 Feb 2006 12:37:51 -0500
Message-ID: <4347.1140802671@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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.

> 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