Re: how to gate experimental features (SQL/PGQ)
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Jacob Champion <jacob.champion@enterprisedb.com>,
Peter Eisentraut <peter@eisentraut.org>, "David G. Johnston" <david.g.johnston@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>,
Jelte Fennema-Nio <postgres@jeltef.nl>
Date: 2026-01-15T17:23:52Z
Lists: pgsql-hackers
Hi, Sorry for the duplicate email, I somehow corrupted the last one. On 2026-01-15 12:05:44 -0500, Andrew Dunstan wrote: > > On 2026-01-13 Tu 12:24 PM, Tom Lane wrote: > > Jacob Champion<jacob.champion@enterprisedb.com> writes: > > > On Tue, Jan 13, 2026 at 7:17 AM Andres Freund<andres@anarazel.de> 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