Re: Incorrect processing of CREATE TRANSFORM with DDL deparding

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: Incorrect processing of CREATE TRANSFORM with DDL deparding
Дата
Msg-id 20150527014625.GG26667@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: Incorrect processing of CREATE TRANSFORM with DDL deparding  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-bugs
Alvaro,

* Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
> 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?
>=20
> 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.

Yeah, good points, all of them.

> 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.
>=20
> 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() ...
>=20
> Anyway this would solve the problem at hand anyway.

I certainly agree that being able to centralize those arrays would be
nice.  It has definitely struck me, more than once, that we've got quite
a few different arrays hanging around that might be better combined into
one or at least kept in the same area.  If nothing else, it might help
minimize cases where individuals forget to update one or another of the
arrays.

    Thanks!

        Stephen

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Venkata Balaji N
Дата:
Сообщение: Re:
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: BUG #13126: table constraint loses its comment