On Tue, Apr 9, 2013 at 12:07 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > I wrote: >> Dimitri Fontaine <dimi...@2ndquadrant.fr> writes: >>> What about splitting the big switch statement into two of them? The >>> first one for transaction control statements, and then the other bigger >>> one. > >> Sounds like considerable uglification to fix a performance issue that's >> entirely hypothetical... let's see some numbers that prove it's worth >> worrying about before we do that. > > 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. > > 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.
I kind of wonder if there's some way we could split ProcessUtility() up into more digestible pieces. I can't really think of a good way to do it though, without writing duplicative switches. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
