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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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