Re: Parser Cruft in gram.y - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Parser Cruft in gram.y
Date
Msg-id m2ehis2ptg.fsf@2ndQuadrant.fr
Whole thread Raw
In response to Re: Parser Cruft in gram.y  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Switching timeline over streaming replication
Next
From: David Gould
Date:
Subject: Re: Re: bulk_multi_insert infinite loops with large rows and small fill factors