Joe Conway wrote:
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
On Mon, Oct 14, 2002 at 12:04:14AM -0400, Tom Lane wrote:
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
On Mon, 14 Oct 2002, Tom Lane wrote:
Gavin Sherry [EMAIL PROTECTED] writes:
On Sat, 12 Oct 2002, Joe Conway wrote:
Tom Lane wrote:
Hackers: we might reasonably fix this by doing a deep copy of the
relcache's trigger info during initResultRelInfo(); or we could fix it
by getting rid of
On Mon, 14 Oct 2002, 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
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
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
Marc G. Fournier [EMAIL PROTECTED] writes:
On Mon, 14 Oct 2002, 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
