On Tue, Apr 9, 2013 at 12:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
>> Dimitri Fontaine <dimitri@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
