Re: Triggers, again.. ;-)

> Phil Endecott <spam_from_postgresql_general(at)chezphil(dot)org> writes:
>> I would understand this if I were doing an "ALTER TABLE", for example.
>> But does adding or removing a trigger really count as "schema-altering"?
>
> [ shrug... ] Hard to say. Probably depends a lot on what the trigger
> does. I suppose we could at least reduce the lock from AccessExclusive
> to Exclusive, which would allow concurrent readers (since SELECT by
> definition doesn't fire any triggers).
>
> No one's really gone through and taken a hard look at whether every
> single DDL operation needs the maximum lock ...
>
> regards, tom lane
>

FYI, I did experience locking issues (my attempt to drop the trigger
resulted in other sessions blocking)...

In any event, I found a solution which at first seemed stupid, but works
so great I thought I'd share it...

All I did was added an extra column to my table "batch_process". Then in
the trigger do something like:

IF NEW.batch_process THEN
NEW.batch_process := NULL;
RETURN NULL;
END IF;
.. whatever the rest of transaction is

Then when doing an insert, just:

INSERT INTO table (..., batch_process) VALUES (..., 't') when you want the
trigger not to fire...

What do you guys think?.. Is this dumb?....

- Greg