"m...@rpzdesign.com" <m...@rpzdesign.com> writes: > You may want to consider changing the command TRIGGER into a command FILTER > and possibly post processing TRIGGER that > is determined to be called INSIDE the FILTER. Or some way to pass > information between the FILTER and the post processing trigger.
The only current "event" supported by the system is the "ddl_command_start" one. We mean to add some more, and triggers wanting to communicate data in between "ddl_command_start" and "ddl_command_end" (for example) will have to use something like a table. > Also, something information as to whether a series of statements was ROLLED > BACK would be helpful. Event Triggers are not an autonomous transaction: any effect they have in the database is rolled-backed when the main transaction is rolled backed. You can use LISTEN/NOTIFY or PGQ that both know how to handle that semantics. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
