Re: [COMMITTERS] pgsql: Add sql_drop event for event triggers - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [COMMITTERS] pgsql: Add sql_drop event for event triggers
Date
Msg-id 2768.1365523654@sss.pgh.pa.us
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Add sql_drop event for event triggers  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [COMMITTERS] pgsql: Add sql_drop event for event triggers
Re: [COMMITTERS] pgsql: Add sql_drop event for event triggers
List pgsql-hackers
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.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: Add sql_drop event for event triggers
Next
From: "Stephen R. van den Berg"
Date:
Subject: page 1 of relation global/11787 was uninitialized