Re: Parser Cruft in gram.y

Поиск
Список
Период
Сортировка
От David Fetter
Тема Re: Parser Cruft in gram.y
Дата
Msg-id 20121219142115.GA18486@fetter.org
обсуждение исходный текст
Ответ на Re: Parser Cruft in gram.y  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Список pgsql-hackers
On Tue, Dec 18, 2012 at 10:33:12AM +0100, Dimitri Fontaine wrote:
> Robert Haas <robertmhaas@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 <tgl@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 <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Switching timeline over streaming replication
Следующее
От: Jeff Janes
Дата:
Сообщение: Re: [PERFORM] Slow query: bitmap scan troubles