Re: [COMMITTERS] pgsql: Add sql_drop event for event triggers
От | Dimitri Fontaine |
---|---|
Тема | Re: [COMMITTERS] pgsql: Add sql_drop event for event triggers |
Дата | |
Msg-id | m2obdna3rx.fsf@2ndQuadrant.fr обсуждение исходный текст |
Ответ на | 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 |
Tom Lane <tgl@sss.pgh.pa.us> writes: > Yeah, I was just looking at the IfSupported variant. In the structure > I just suggested (separate ProcessSlowUtility function), we could make > that work by having switch cases for some statements in both functions, > perhaps like this: Ah yes, that's minimal code duplication and cleaner effect. > RenameStmt: > if (stmt allows event triggers) > ProcessSlowUtility(...); > else > ExecRenameStmt(stmt); > break; > > while in ProcessSlowUtility it'd just look normal: > > RenameStmt: > ExecRenameStmt(stmt); > break; I like it globally. Do you think some inline magic needs to happen to try and convince the compiler to process the whole thing as a single function? My understanding is that while there's no way to require the inlining to happen we still have some provisions to hint the compilers wanting to listen, or something like that. > This would also get rid of the assumption that's currently wired into > InvokeDDLCommandEventTriggersIfSupported that the only sort of dynamic > test that can be needed is an EventTriggerSupportsObjectType call. > In the sketch above, the if() could be testing any property of the stmt. And even better, could easily be made different from a call site to the next, by simply upgrading the complex command into the main utility switch. Do you want me to work on a patch at the end of this week? Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
В списке pgsql-hackers по дате отправления: