Re: reducing the footprint of ScanKeyword (was Re: Large writablevariables) - Mailing list pgsql-hackers

From Andres Freund
Subject Re: reducing the footprint of ScanKeyword (was Re: Large writablevariables)
Date
Msg-id 20181227131953.fnspabit3lq56lej@alap3.anarazel.de
Whole thread Raw
In response to Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

On 2018-12-26 14:03:57 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > My bet is, and has been for quite a while, that we'll have to go for a
> > hand-written recursive descent type parser.
> 
> I will state right up front that that will happen over my dead body.
> 
> It's impossible to write correct RD parsers by hand for any but the most
> trivial, conflict-free languages, and what we have got to deal with
> is certainly neither of those; moreover, it's a constantly moving target.
> We'd be buying into an endless landscape of parser bugs if we go that way.
> It's *not* worth it.

It's not exactly new that people end up moving to bison to recursive
descent parsers once they hit the performance problems and want to give
better error messages. E.g. both gcc and clang have hand-written
recursive-descent parsers for C and C++ these days.   I don't buy that
we're inable to write a descent parser that way.

What I *do* buy is that it's more problematic for the design of our SQL
dialect, because the use of bison often uncovers ambiguities in new
extensions of the language. And I don't really have a good idea how to
handle that.

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Feature: temporary materialized views
Next
From: Andres Freund
Date:
Subject: Re: global / super barriers (for checksums)