Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
