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

From: Joe Conway <mail(at)joeconway(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>, Laurette Cisneros <laurette(at)nextbus(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Disabling triggers (was Re: pgsql 7.2.3 crash)
Date: 2002-10-14 04:15:08
Message-ID: 3DAA44CC.1030501@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-10-14 04:15:51 Re: experiences with autocommit functionality in 7.3
Previous Message Bruce Momjian 2002-10-14 04:13:39 Re: Disabling triggers (was Re: pgsql 7.2.3 crash)