Re: reducing the footprint of ScanKeyword (was Re: Large writablevariables)
От | Andres Freund |
---|---|
Тема | Re: reducing the footprint of ScanKeyword (was Re: Large writablevariables) |
Дата | |
Msg-id | 20181227131953.fnspabit3lq56lej@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: reducing the footprint of ScanKeyword (was Re: Large writable variables) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)
|
Список | 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 по дате отправления: