Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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.

Dimitri Fontaine     PostgreSQL : Expertise, Formation et Support

Attachment: event_trigger_infos.1.patch.gz
Description: application/octet-stream (22.0 KB)

In response to

pgsql-hackers by date

Next:From: Willem LeenenDate: 2012-11-04 20:21:53
Subject: Re: Arguments to foreign tables?
Previous:From: Tom LaneDate: 2012-11-04 20:13:00
Subject: Re: Arguments to foreign tables?

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group