CREATE TRIGGER ... FOR EACH STATEMENT

CREATE TRIGGER ... FOR EACH STATEMENT

am 04.11.2004 23:16:29 von Mischa Sandberg

I notice a dearth of description of the FOR EACH STATEMENT flavour of
triggers, even though OLD_TABLE and NEW_TABLE are mentioned.

After years of Sybase & MSSQL, being able to deal with the entire
INSERTED/DELETED rowsets in a trigger, rather than nibbling away
row by row, has been a great efficiency boost. In fact, the only I've
resorted to FOR EACH ROW triggers is where joining OLD_TABLE and
NEW_TABLE by primary key burned the CPU --- both pseudo-tables being
very large in some updates, and perforce having no indexes ...

I can see from src/backend/command/trigger.c that
ExecASInsertTriggers() would have a hard time getting at the equivalent
of OLD_TABLE and NEW_TABLE, ExecBSInsertTriggers even worse.

Anyone else out there who feels this would be a significant
enhancement?

Re: CREATE TRIGGER ... FOR EACH STATEMENT

am 05.11.2004 04:27:44 von Mischa Sandberg

Please ignore this, I just caught up with news in c.d.p.hackers

Mischa Sandberg wrote:
> I notice a dearth of description of the FOR EACH STATEMENT flavour of
> triggers, even though OLD_TABLE and NEW_TABLE are mentioned.
>
> After years of Sybase & MSSQL, being able to deal with the entire
> INSERTED/DELETED rowsets in a trigger, rather than nibbling away
> row by row, has been a great efficiency boost. In fact, the only I've
> resorted to FOR EACH ROW triggers is where joining OLD_TABLE and
> NEW_TABLE by primary key burned the CPU --- both pseudo-tables being
> very large in some updates, and perforce having no indexes ...
>
> I can see from src/backend/command/trigger.c that
> ExecASInsertTriggers() would have a hard time getting at the equivalent
> of OLD_TABLE and NEW_TABLE, ExecBSInsertTriggers even worse.
>
> Anyone else out there who feels this would be a significant
> enhancement?