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. >> actually, thinking about this, for something like Slony, exposing >> pg_dropped_objects() to ddl_command_end triggers should be just as >> good, and maybe a whole lot better, than what I was proposing. > > It also changes the protocol to use for getting at the information > related to the objects. I think we will have to have the out parameters > of the function to grow to include the next information we're going to > make available to TG_* variables in the next patch of the series. > >> Does it work for you to rip out sql_drop and just make >> pg_dropped_objects() - perhaps renamed - available in ddl_command_end? > > I did rename pg_dropped_objects() and it's now available in > ddl_command_end, but I kept the new "sql_drop" event, which is now > called once per object dropped, as intended (but without any useful > information yet). > > What do you think? Well, having spent a year or more trying to convince you that we need sql_drop - mostly because of the complexities of passing an array of arguments to the trigger function - I now think we don't, because the pg_event_trigger_dropped_objects() bit solves that problem rather elegantly. It seems to me with just a little bit of hacking we should be able to make this work by adding that function and changing nothing else. I might be wrong, of course. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
