Skip site navigation (1) Skip section navigation (2)

Re: hint infrastructure setup (v3)

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: hint infrastructure setup (v3)
Date: 2004-04-05 15:04:57
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
Tom Lane wrote:

>Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> writes:
>>(b) write a new "recursive descendant" parser, and drop "gram.y"

er, that's "recursive descent" :-)

>Been there, done that, not impressed with the idea.  There's a reason
>why people invented parser generators...

Well, unless you are a serious masochist, cutting a parser of the LR 
family (including LALR(1), such as yacc/bison produce) by hand is very 
difficult and error prone. That is not the case with LL type parsers. 
Also, there are parser generators for this family, both table driven and 
recursive descent. The table driven variety especially can have quite 
well tuned error reporting and recovery. (Among the reasons I know this 
is that I actually wrote such a beast around 13 years ago).

That is not to say that I think we should move from the present setup. 
Familiarity of the developer community with the tool used suggests we 
should not, quite apart from any other reasons. Changing to, say, an RD 
parser, would be a massive and probably error prone change and the 
benefit just doesn't seem worth it.

In fact, considering this thread I'm not sure any of the suggested steps 
will achieve Fabien's goal. ISTM that a smarter "training wheels" 
frontend, perhaps with some modest backend improvements, is likely to 
have better results. ("Oh, you found an error near there - now what do I 
suggest belongs there?")



In response to


pgsql-patches by date

Next:From: Stephen FrostDate: 2004-04-05 15:30:30
Subject: Add error-checking to timestamp_recv
Previous:From: Tom LaneDate: 2004-04-05 14:36:11
Subject: Re: hint infrastructure setup (v3)

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group