Parser Cruft in gram.y

Поиск
Список
Период
Сортировка
От Dimitri Fontaine
Тема Parser Cruft in gram.y
Дата
Msg-id m2r4ms2v3o.fsf_-_@2ndQuadrant.fr
обсуждение исходный текст
Ответ на Re: Use of systable_beginscan_ordered in event trigger patch  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Parser Cruft in gram.y
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> ISTM that a PGC_SUSER GUC, as I proposed previously, would serve this
> need adequately, without the cost of more cruft in gram.y.

I can't help but think about the experiments you did some time ago about
splitting the grammar into differents sub-grammars (for lack of a better
term). If I remember correctly, your result showed no performance gain
from separating away Queries and DML on the one side from the rest, DDL
and DCL and such like.

IIRC, you didn't have a regression either.

Now, what about splitting those grammars in order to freely add any new
production rules with or without new keywords for administrative
commands, without a blink of though about the main parser grammar.

I guess that the "traffic cop" would need to have a decent fast path to
very quickly get to use the right parser, and I suppose you did already
implement that in your previous experiment.

If that's sensible as a way forward, that can also be the basis for
allowing extensions to implement their own command set too. The trick
would be how to implement extensible grammar routing. That would come
way after we have the initial split, though.

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support



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

Предыдущее
От: Любен Каравелов
Дата:
Сообщение: Re: Use gcc built-in atomic inc/dec in lock.c
Следующее
От: Tom Lane
Дата:
Сообщение: Adjusting elog behavior in bootstrap/standalone mode