Re: [COMMITTERS] pgsql: Add sql_drop event for event triggers
От | Robert Haas |
---|---|
Тема | Re: [COMMITTERS] pgsql: Add sql_drop event for event triggers |
Дата | |
Msg-id | CA+TgmoZK-DddbTY9T9uFVyi2_+jj1fREk5fbR2YRTBGVC5DNVw@mail.gmail.com обсуждение исходный текст |
Ответ на | 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
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: