From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: Incorrect processing of CREATE TRANSFORM with DDL deparding |
Date: | 2015-05-26 14:41:40 |
Message-ID: | 20150526144140.GT5885@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Ivette Ruiz Vertiz | 2015-05-26 15:48:39 | formato de Fechas |
Previous Message | Sharma, Krishna Kumar | 2015-05-26 13:55:49 | Re: BUG #13324: Database returing incorrect results on querying slect clause |