Robert Haas <robertmhaas@gmail.com> writes:
> Taking a first look at this, I think the idea of pg_dropped_objects()
> is really pretty clever. I like it. I assure we will end up with
> several functions of this type eventually, so it might be good to
> adopt some kind of distinguishing naming convention for this type of
> function. pg_event_trigger_context_dropped_objects() seems far too
> verbose, but that's the idea.
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().
> 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.
So in the attached, I've made the sql_drop an event triggers called once
per object, which means that currently you only know an object is
getting DROPed as part of a DROP TABLE command.
> 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?
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support