Parser Cruft in gram.y

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