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

Re: sql_drop Event Triggerg

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: sql_drop Event Triggerg
Date: 2013-03-29 08:27:47
Message-ID: m2fvzewqyk.fsf@2ndQuadrant.fr (view raw or flat)
Thread:
Lists: pgsql-hackers
Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> Pushed, with some further minor changes.  One not-so-minor change I

Thanks a lot for all the work you did put into this patch!

> introduced was that pg_event_trigger_dropped_objects() now only works
> within a sql_drop event function.  The reason I decided to do this was
> that if we don't have that protection, then it is possible to have a
> ddl_command_end trigger calling pg_event_trigger_dropped_objects(); and
> if there is an sql_drop trigger, then it'd return the list of dropped
> objects, but if there's no sql_drop trigger, it'd raise an error.  That
> seemed surprising enough action-at-a-distance that some protection is
> warranted.

+1

I hope that we can add another such function for ddl_command_start and
ddl_command_end function to get at some object information from there,
now that the support code is in place.

That would allow making any use of the event trigger facility in 9.3
without having to write a C coded extension… which has been the goal for
the last two cycles…

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support


In response to

pgsql-hackers by date

Next:From: Dimitri FontaineDate: 2013-03-29 09:44:00
Subject: Re: in-catalog Extension Scripts and Control parameters (templates?)
Previous:From: Andres FreundDate: 2013-03-29 07:05:00
Subject: Re: Enabling Checksums

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