Re: Incorrect processing of CREATE TRANSFORM with DDL deparding

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