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