Re: Disabling triggers (was Re: pgsql 7.2.3 crash)

Поиск
Список
Период
Сортировка
От Joe Conway
Тема Re: Disabling triggers (was Re: pgsql 7.2.3 crash)
Дата
Msg-id 3DAA44CC.1030501@joeconway.com
обсуждение исходный текст
Ответ на Re: pgsql 7.2.3 crash  (Gavin Sherry <swm@linuxworld.com.au>)
Ответы Re: Disabling triggers (was Re: pgsql 7.2.3 crash)  (Kevin Brown <kevin@sysexperts.com>)
Список pgsql-hackers
Tom Lane wrote:
> I was wondering whether an ALTER TABLE command is really the right way
> to approach this.  If we had an ALTER-type command, presumably the
> implication is that its effects would be global to all backends.  But
> the uses that I've seen for suspending trigger invocations would be
> happier with a local, temporary setting that only affects the current
> backend.  Any thoughts about that?
> 

Hmmm. Well the most common uses I've run across for disabling triggers in the  Oracle Apps world are:

1) bulk loading of data
2) temporarily turning off "workflow" procedures

The first case would benefit from being able to disable the trigger locally, 
without affecting other backends. Of course, I don't know how common it is to 
bulk load data while others are hitting the same table.

The second case is usually something like an insert into the employee table 
fires off an email to IT to create a login and security to make a badge. 
Commonly we turn off workflows (by disabling their related triggers) in our 
development and test databases so someone doesn't disable the CEO's login when 
we fire him as part of our testing! I think in this scenario it is better to 
be able to disable the trigger globally ;-)

Joe






В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: experiences with autocommit functionality in 7.3
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Disabling triggers (was Re: pgsql 7.2.3 crash)