Re: tsearch in core patch, for inclusion - Mailing list pgsql-hackers

From Florian G. Pflug
Subject Re: tsearch in core patch, for inclusion
Date
Msg-id 45DC5E45.4060206@phlo.org
Whole thread Raw
In response to Re: tsearch in core patch, for inclusion  (Markus Schiltknecht <markus@bluegap.ch>)
Responses Re: tsearch in core patch, for inclusion  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Markus Schiltknecht wrote:
>>> Are there any ongoing efforts to rewrite the parser (i.e. using 
>>> another algorithm, like a recursive descent parser)?
>> Why would you want to do that?
> 
> I recall having read something about rewriting the parser. Together with 
> Tom being worried about parser performance and knowing GCC has switched 
> to a hand written parser some time ago, I suspected bison to be slow. 
> That's why I've asked.

I think the case is different for C and C++. The grammars of C and C++
appear to be much more parser-friendly then SQL, making handcrafting
a parser easier I'd think. And I believe that one of the reasons gcc 
wasn't happy with bison was that I limited the quality of their error 
reporting - which isn't that much of a problem for SQL, since SQL 
statements are rather short compared to your typical C/C++ source file.

Last, but not least, the C and C++ syntax is basically set in stone - At
least now the g++ supports nearly all (or all? don't know) of the C++ 
standard. So it doesn't really matter if changes to the parse are a bit 
more work, because the rarely happen. Postgres seems to add new features 
that change the grammar with every release (with is a good thing!).

greetings, Florian Pflug


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Column storage positions
Next
From: "Florian G. Pflug"
Date:
Subject: Re: Column storage positions