Dimitri Fontaine <dimi...@2ndquadrant.fr> writes: > The current design for event triggers is to spit out several things: > > - command tag is already commited > - object id, can be null > - schema name, can be null > - object name > - operation either ALTER, CREATE or DROP, … > - object type TABLE, VIEW, FUNCTION, … > - normalized command string > > After some more thinking, it appears that in several case you want to > have all those information filled in and you don't want to care if that > means your trigger needs to run at ddl_command_start or ddl_command_end. > > The proposal I want to make here is to introduce a generic event (or an > event alias) named ddl_command_trace that the system provides at the > right spot where you have the information. That's useful when you don't > intend to divert the execution of the DDL and need to know all about it.
Please find attached a patch that includes support for such a design. > For a DROP operation, ddl_command_trace would be ddl_command_start, and > for a CREATE operation, that would be ddl_command_end, so that the > target object (still|already) exists when the trigger is fired. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
event_trigger_infos.1.patch.gz
Description: Added Information for Event Triggers
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
