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
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) |