Re: Proposal for Disable Triggers

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Proposal for Disable Triggers
Дата
Msg-id 20040807221937.GB5273@dcc.uchile.cl
обсуждение исходный текст
Ответ на Proposal for Disable Triggers  (fastpgs <fastpgs@fast.fujitsu.com.au>)
Ответы Re: Proposal for Disable Triggers  (fastpgs <fastpgs@fast.fujitsu.com.au>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Postgres development model (was Re: CVS comment)
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Regarding redo/undo files.