Hi, On 2026-01-15 12:05:44 -0500, Andrew Dunstan wrote: > On 2026-01-13 Tu 12:24 PM, Tom Lane wrote: > > Jacob Champion<[email protected]> writes: > > > On Tue, Jan 13, 2026 at 7:17 AM Andres Freund<[email protected]> wrote: > > > > I don't even know how you could implement 3) realistically. We have zero > > > > infrastructure for making e.g. parser, keyword list etc change due to > > > > defines > > > > compile time. > > > Is that an architecturally unsolvable thing, or is it a simple matter > > > of programming? Would it be nice to have said infrastructure? > > You'd have to throw out flex and bison and build some sort of > > extensible parser. That has some attraction to me personally > > (I worked on such systems decades ago at HP), but it's fairly > > hard to justify the amount of effort that would be needed to > > get there. It might well be slower than a flex/bison parser, > > and/or have poorer detection of grammar inconsistencies, either > > of which would be bad for our usage. > > > Maybe, but maybe not. ISTR that gcc abandoned use of bison for their C > compiler a long time ago, and that gnat's Ada compiler was hand cut from the > get go. > > SQL is a different kettle of fish, of course - it dwarfs C and Ada in > complexity.
The handwritten parser is also used for C++ which is *quite* a bit more complicated than C, and probably roughly on-par with SQL. I think the situation for C like languages is a bit different than with SQL though, because typically the compiler specific syntax extensions are much more modest than with SQL. Due to the different compilers for C like language, it's probably easier to find grammar / language issues than for something like postgres SQL dialect, which differs substantially from other SQL implementations and thus only has a single parser. That said, I do suspect we might eventually want to just give up on the "parser generator as a sanity check" aspect and go with a hand written recursive descent parser. For speed, extensibility and better error recovery/messages. Greetings, Andres Freund
