On Tue, Dec 18, 2012 at 10:33:12AM +0100, Dimitri Fontaine wrote: > Robert Haas <robertmh...@gmail.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.
In addition to this, there could well be uses for a more modular parser. For example, if it turns out to be possible to do our parser in a way that is exportable and (can be converted to a type that) looks forward, client code could do a lot of interesting (and provably correct) things. > 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 <t...@sss.pgh.pa.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/ More angles: http://wwwiti.cs.uni-magdeburg.de/~rosenmue/publications/SKS+08.pdf Might anyone here wish to investigate this, given some kind of resources for the initial study? Cheers, David. -- David Fetter <da...@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
