Re: Parser Cruft in gram.y

Tom Lane <tgl@sss.pgh.pa.us> writes:
> Let me explain to you why there will never be a situation where we can
> consider new keywords to be zero-cost.

Thanks for taking the time to do this.

> Splitting the grammar into multiple grammars is unlikely to do much to
> improve this --- in fact, it could easily make matters worse due to
> duplication.  Rather, we just have to be careful about adding new
> keywords.  In this connection, I quite like the fact that recent syntax
> extensions such as EXPLAIN (...options...) have managed to avoid making
> the option names into grammar keywords at all.

I'm still pretty unhappy about this state of affairs. I would like to
have a fast path and a "you can go crazy here" path.

Apparently the solutions to reduce the footprint involve hand made
recursive decent parsers which are harder to maintain.

I've read a little about the packrat parsing techniques, but far from
enough to understand how much they could help us solve the binary bloat
problem we have here while not making it harder to maintain our grammar.

Maybe some other techniques are available…

Ideas? Or should I just bite the bullet?
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support