Re: Disabling triggers (was Re: pgsql 7.2.3 crash) - Mailing list pgsql-hackers

From Joe Conway
Subject Re: Disabling triggers (was Re: pgsql 7.2.3 crash)
Date
Msg-id 3DAA44CC.1030501@joeconway.com
Whole thread Raw
In response to Re: pgsql 7.2.3 crash  (Gavin Sherry <swm@linuxworld.com.au>)
Responses Re: Disabling triggers (was Re: pgsql 7.2.3 crash)
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: experiences with autocommit functionality in 7.3
Next
From: Tom Lane
Date:
Subject: Re: Disabling triggers (was Re: pgsql 7.2.3 crash)