From: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> |
---|---|
To: | fastpgs <fastpgs(at)fast(dot)fujitsu(dot)com(dot)au> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Proposal for Disable Triggers |
Date: | 2004-08-07 22:19:37 |
Message-ID: | 20040807221937.GB5273@dcc.uchile.cl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2004-08-07 22:27:17 | Re: Regarding redo/undo files. |
Previous Message | Oliver Elphick | 2004-08-07 21:43:04 | Re: UNICODE characters above 0x10000 |