Re: how to gate experimental features (SQL/PGQ)

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<jacob(dot)champion(at)enterprisedb(dot)com> writes:
> > > On Tue, Jan 13, 2026 at 7:17 AM Andres Freund<andres(at)anarazel(dot)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