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

Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> 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.

> That needs either lots of code duplication or some smarts that I don't
> see yet, because of the EventTriggerSupportsObjectType stuff. Anyways
> I'm not much into C macrology myself

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:

RenameStmt:
if (stmt allows event triggers)
ProcessSlowUtility(...);
else
ExecRenameStmt(stmt);
break;

while in ProcessSlowUtility it'd just look normal:

RenameStmt:
ExecRenameStmt(stmt);
break;

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.

regards, tom lane