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

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.

Not saying I think this would be a good thing or not. I agree that the
effort required would be huge and the benefit might be modest, but it is
feasible IMHO.

cheers

andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com