Robert Haas escribió:
> On Mon, Feb 4, 2013 at 11:59 AM, Dimitri Fontaine
> <dimitri@2ndquadrant.fr> wrote:
> > Thanks. Agreed that we will have more of them. In the attached version 3
> > of the patch, it got renamed to pg_event_trigger_dropped_objects().
>
> Works for me.
>
> >> With this approach, there's no real need to introduce a new event
> >> type. We could just make ddl_command_end triggers able to use this,
> >> and we're done. The point of sql_drop was that it would have been
> >> called once *per dropped object*, not once per command. But,
> >
> > Well, from the beginning of the sql_drop discussion, it's been clear
> > that it's meant to allow for users to easily attach their function to
> > any drop that might appear, whatever the command at origin of that drop.
>
> What precludes us from doing that in ddl_command_end? ISTM we can
> just extend the ddl_command_start/end triggers to a slightly broader
> range of commands and be done with it.
I thought there was the idea that the list of objects to drop was to be
acquired before actually doing the deletion; so that the trigger
function could, for instance, get the name of the table being dropped.
I don't see that it works if we only provide
pg_event_trigger_dropped_objects to ddl_command_end events. Am I
missing something?
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services