Re: Proposal for Disable Triggers

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

In response to

Responses

Browse pgsql-hackers by date

  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