Re: [COMMITTERS] pgsql: Add sql_drop event for event triggers
От | Dimitri Fontaine |
---|---|
Тема | Re: [COMMITTERS] pgsql: Add sql_drop event for event triggers |
Дата | |
Msg-id | m2ehejbrhk.fsf@2ndQuadrant.fr обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Add sql_drop event for event triggers (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [COMMITTERS] pgsql: Add sql_drop event for event triggers
|
Список | pgsql-hackers |
Tom Lane <tgl@sss.pgh.pa.us> writes: > Actually ... wait a moment. That does have some attraction independent > of performance questions, because what Alvaro suggested requires knowing > which commands support command triggers in two places. Perhaps with > some refactoring we could end up with no net addition of cruft. That was the idea yes, that's the right context now. About the refactoring itself, how much do we want to keep the compiler help about covering all the items in the switch? Other than that, changing the breaks into returns in the first switch looks like it would do the work, we don't even need a goto cleanup. > Personally, I'd really like to see the InvokeDDLCommandEventTriggers > macros go away; that's not a coding style I find nice. If we had a > separate switch containing just the event-supporting calls, we could > drop that in favor of one invocation of the trigger stuff before and > after the switch. That needs either lots of code duplication or some smarts that I don't see yet, because of the EventTriggerSupportsObjectType stuff. Anyways I'm not much into C macrology myself… At best I can find some time and work on that from Thursday. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
В списке pgsql-hackers по дате отправления: