Stephen Frost wrote:
> That said, I'm really not all that happy with the split between
> ProcessUtility() and ProcessUtilitySlow(). I've not said anything since
> I haven't got any great solutions to the issue, but it really is pretty
> grotty. I realize it might take a few extra cycles, but my thinking is
> along the lines of having an array or similar which we scan that
> indicates what is supported by deparse/event triggers, what isn't, etc,
> and then we operate based on that.. Perhaps an array which is indexed
> based on the NodeTag enum?
That doesn't work. Consider DropStmt for example; it is supported for
some object types, but not supported by others. There are a few other
commands for which this happens too. Also, NodeTag contains tags for
everything that can be a node: plan nodes for example, and for those it
doesn't even make sense to consider whether event triggers are
supported.
I suppose you could create a node type T_UtilityStmt and make all the
command nodes be sub-types of that one. But, except for the
ProcessUtility{Slow} code, it would be a loss in maintainability, ISTM,
and it would increase the size of every single utility node.
Now maybe with that you could get rid of (or centralize) various arrays;
see for example ObjectTypeMap and event_trigger_support, the calls to
pg_strcasecmp() in check_ddl_tag, EventTriggerSupportsObjectType() and
EventTriggerSupportsObjectClass() and
EventTriggerSupportsGrantObjectType() ...
Anyway this would solve the problem at hand anyway.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services