Re: Deparsing DDL command strings

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Jim Nasby <jim(at)nasby(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Deparsing DDL command strings
Date: 2012-11-04 20:19:46
Message-ID: m2liehktnh.fsf@2ndQuadrant.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)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

Attachment Content-Type Size
event_trigger_infos.1.patch.gz application/octet-stream 22.0 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Willem Leenen 2012-11-04 20:21:53 Re: Arguments to foreign tables?
Previous Message Tom Lane 2012-11-04 20:13:00 Re: Arguments to foreign tables?