Robert Haas escribió: > On Mon, Feb 4, 2013 at 11:59 AM, Dimitri Fontaine > <dimi...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
