Re: [COMMITTERS] pgsql: Add sql_drop event for event triggers

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [COMMITTERS] pgsql: Add sql_drop event for event triggers
Дата
Msg-id 2768.1365523654@sss.pgh.pa.us
обсуждение исходный текст
Ответ на 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  (Robert Haas <robertmhaas@gmail.com>)
Re: [COMMITTERS] pgsql: Add sql_drop event for event triggers  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Add sql_drop event for event triggers
Следующее
От: "Stephen R. van den Berg"
Дата:
Сообщение: page 1 of relation global/11787 was uninitialized