On Sun, 8 Aug 2004 08:19, Alvaro Herrera wrote:
> If the change is global, what should happen on other sessions that have
> a deferred event from that trigger concurrently with the one that
> modifies it? Should the answer be different depending on the isolation
> mode of the transaction?
This was my other question.... It depends on how we are going to treat the
trigger already on the deferred stack... Are we going to execute the trigger
as if its status wasn't changed or are we going to double check its status
just before executing the trigger body ??
> Also, should the change be permanent, or should it be undone when the
> modifying backend exits (or the transaction ends)?
>
> I don't think it makes a lot of sense to be changing triggers globally.
> Usually you want to change it only to do a certain operation, without
> worrying about concurrent transactions.
My preference is for the change being permanent... Sure in most cases the
user would want the trigger disabled for certain operations.. But there would
be scnearios where the user would want it not be executed for a longer period
of time... In either cases the user is the best one to know when to enable
the trigger back...
Rgds,
Arul
This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN 27 003 693
481. It is confidential to the ordinary user of the email address to which it was
addressed and may contain copyright and/or legally privileged information. No one else
may read, print, store, copy or forward all or any of it or its attachments. If you
receive this email in error, please return to sender. Thank you.
If you do not wish to receive commercial email messages from Fujitsu Australia
Software Technology Pty Ltd, please email [EMAIL PROTECTED]
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
