Here's an implementation of what we discussed: the event is now DDL_DROP
and is called inside performDeletion and performMultipleDeletions; it
receives the list of objects via pg_dropped_objects (though it now has a
more verbose name), and the objects are still catalogued when the
trigger is called. This event does *not* receive the parsetree (as
opposed to ddl_command_start/end); also, there's no tag filtering
support, so if you install a function in that event, it will run every
time a DROP of any kind occurs.
I have added some protections so that these do not fire on undesirable
events (such as dropping an event trigger); also event triggers and
other object types are filtered out of pg_dropped_objects, in case
something like DROP OWNED happens. (So for instance you could get an
empty pg_dropped_objects if you did DROP OWNED and the mentioned user
only owns an event trigger). Maybe this needs to be reconsidered.
There's also code to re-obtain the list of objects to drop after the
event trigger functions have run; the second list is compared to the
first one, and if they differ, an error is raised.
It's rather annoying that performMultipleDeletions and performDeletion
contain almost exactly the same code. I think maybe it's time to morph
the latter into a thin layer on top of the former.
(small remaiing issue: docs need updated).
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
