| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> |
| Subject: | Re: how to gate experimental features (SQL/PGQ) |
| Date: | 2026-01-15 17:23:52 |
| Message-ID: | u52xp65wlf5vng32bs5lwsjduardjkyn5o5nzeqij2epo34qxw@rcfpt4v2crux |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| 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(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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sami Imseih | 2026-01-15 17:25:18 | Re: Flush some statistics within running transactions |
| Previous Message | Andres Freund | 2026-01-15 17:21:15 | Re: how to gate experimental features (SQL/PGQ) |