Re: Proposal for Disable Triggers - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Proposal for Disable Triggers
Date
Msg-id 20040807221937.GB5273@dcc.uchile.cl
Whole thread Raw
In response to Proposal for Disable Triggers  (fastpgs <fastpgs@fast.fujitsu.com.au>)
Responses Re: Proposal for Disable Triggers  (fastpgs <fastpgs@fast.fujitsu.com.au>)
List pgsql-hackers
On Fri, Aug 06, 2004 at 03:14:13PM +1000, fastpgs wrote:

> And finally about the scope of the change of status of a trigger.
> Should this be local to the session or should be reflected globally?
> My humble opinion is it should be reflected globally(again, as in
> oracle ?)....

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?

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.  Following that rationale, the
command should not be ALTER, because that's used for permanent changes.
Also, make sure that when a backend crashes, the final state should be
the same as when the backend exits normally.

I'm not sure the Oracle behavior is the one we want to imitate here ...

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
Jude: I wish humans laid eggs
Ringlord: Why would you want humans to lay eggs?
Jude: So I can eat them



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Postgres development model (was Re: CVS comment)
Next
From: Alvaro Herrera
Date:
Subject: Re: Regarding redo/undo files.