I'm glad your curiosity got the best of you ;o)
I was planning to test it out, but didn't have the time to do it. I too, was
very curious as to what the ramifications of dropping the trigger would be in
that scenario. Now, we know :o)
On Monday 24 January 2005 11:07 pm, Jeff Davis saith:
> It g
It got me curious enough that I tested it, and apparently droping a
trigger locks the table. Any actions on that table must wait until the
transaction that drops the trigger finishes.
So, technically my system works, but requires a rather nasty lock while
the transaction (the one that doesn't want
I don't know if droping a trigger inside a transaction will work. Besides
that, we want the trigger to do its work in all other circumstances. With a
hundred connections on the database, I don't know what kind of issues that
would cause if the trigger were there, and suddenly, not there. We figu
Would it work to just do a DROP TRIGGER at the begining of the
transaction and a CREATE TRIGGER at the end?
Regards,
Jeff Davis
On Mon, 2005-01-24 at 06:50 -0500, Terry Lee Tucker wrote:
> Razvan,
>
> I don't believe there is a way of doing this from by way of some postgreSQL
> command.
Razvan,
I don't believe there is a way of doing this from by way of some postgreSQL
command. We accomplish this by creating a table called "override". It is
defined as:
recid | integer| not null default
nextval('public.override_recid_seq'::text)
trig_name | chara
