Re: sql_drop Event Triggerg
Alvaro Herrera <alvherre@2ndquadrant.com>
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Dimitri Fontaine <dimitri@2ndquadrant.fr>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2013-03-27T05:06:33Z
Lists: pgsql-hackers
Attachments
- dropped_objects.10.patch (text/x-diff)
Alvaro Herrera escribió: > However, I think previous discussions have conflated many different > things, and we've been slowly fixing them one by one; so perhaps at this > point it does make sense to have a new object-drop event. Let's discuss > it -- we would define it as taking place just before ddl_command_end, > and firing any time a command (with matching tag?) has called > performDeletion or performMultipleDeletions. Does that sound okay? Here's another version of this patch. I hope this is really final now ... but then, that's what I thought of the previous two versions, too. I have re-instated event sql_drop, which takes place just before ddl_command_end, and is called a single time per command (not once per object dropped, as the old definition would have had it). Within a function running in that event, you can call pg_event_trigger_dropped_object(); that will give you a list of all objects that have been dropped. Since the deletion command has already been run, the objects are not in catalogs anymore. There are no magic TG_* variables about objects deleted. I'm a bit unhappy about having to add calls to EventTriggerSQLDrop() just before each call to EventTriggerDDLCommandEnd(), but I didn't see any way to make this less duplicative. Docs and regression tests have been minimally fixed. The new event is called sql_drop, note. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services