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


---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly

Reply via email to