Re: Parser Cruft in gram.y

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> And on the other hand, if you could get a clean split between the two
> grammars, then regardless of exactly what the split was, it might seem
> a win. But it seemed to me when I looked at this that you'd have to
> duplicate a lot of stuff and the small parser still wouldn't end up
> being very small, which I found hard to get excited about.

I think the goal is not so much about getting a much smaller parser, but
more about have a separate parser that you don't care about the "bloat"
of, so that you can improve DDL without fearing about main parser
performance regressions.

If we come out with no regression and no gain on the main query parser,
I say it still worth the separation effort. And anyway we only add
things to the main parser (queries) when the standard saith we have to.

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> I'm not sure what other tool might be better though. I looked through
> http://en.wikipedia.org/wiki/Comparison_of_parser_generators#Deterministic_context-free_languages
> but it seems our options are a bit limited if we want something
> that produces C. It's not clear to me that any of the likely options
> are as mature as bison, let alone likely to substantially outperform it.
> (For instance, Hyacc sounded pretty promising until I got to the part
> about it doesn't yet support %union or %type.) Still, I didn't spend
> much time on this --- maybe somebody else would like to do a bit more
> research.

I did spend a very little time on it too, with a different search angle,
and did find that "experimental" thing that might be worth looking at,
or maybe not.

http://en.wikipedia.org/wiki/Parsing_expression_grammar
http://piumarta.com/software/peg/

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