Re: Release changes: statement level triggers - Mailing list pgsql-hackers

From Andreas Pflug
Subject Re: Release changes: statement level triggers
Date
Msg-id 3F2FE2FC.2030105@pse-consulting.de
Whole thread Raw
In response to Re: Release changes  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses TODO: trigger features
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Building beta packaging fails ...
Next
From: Joe Conway
Date:
Subject: Re: Release changes