Re: sql_drop Event Trigger
От | Alvaro Herrera |
---|---|
Тема | Re: sql_drop Event Trigger |
Дата | |
Msg-id | 20130205235802.GG5753@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: sql_drop Event Trigger (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: sql_drop Event Trigger
|
Список | pgsql-hackers |
Robert Haas escribió: > 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. I thought there was the idea that the list of objects to drop was to be acquired before actually doing the deletion; so that the trigger function could, for instance, get the name of the table being dropped. I don't see that it works if we only provide pg_event_trigger_dropped_objects to ddl_command_end events. Am I missing something? -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: