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.
>> 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