Dimitri Fontaine <dimitri@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
