Re: Release changes: statement level triggers

Bruce Momjian wrote:

>How are statement level triggers supposed to work? Are they just
>triggers deferred until the end of the statement? You mentioned access
>to the affected rows, but I don't understand how that is supposed to
>happen.
>
>
Statement level isn't about deferring or grouping the trigger execution,
but about the triggering event. While a row level trigger will be called
exactly once for every row being affected, a statement level trigger
will be called exactly once per statement, whatever the result set may
be, so even on a zero-row result set it will run. A standard way to
handle recursivity on this is to check for a zero-row rowset, and
aborting then. But how to obtain information about the rowset?
What's needed is an equivalent to the OLD and NEW
variableTriggerData.tg_newtuple / TriggerData.tg_trigtuple, so that the
result set being
modified can be accessed in queries. Thus statement level triggers are a
combination of rules (where OLD and NEW define the affected rowset), and
row-level triggers, enabling conditial programming etc. For systems
where big chunks of data is inserted or updated in a single statement, a
row-level trigger, while being much easier to implement, could be a big
performance hit.

Regards,
Andreas