Re: Deparsing DDL command strings

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