Re: sql_drop Event Triggerg
От | Alvaro Herrera |
---|---|
Тема | Re: sql_drop Event Triggerg |
Дата | |
Msg-id | 20130327050633.GE3881@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: sql_drop Event Triggerg (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: sql_drop Event Triggerg
|
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: