public inbox for [email protected]  
help / color / mirror / Atom feed
From: Jacob Champion <[email protected]>
To: Tom Lane <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: David G. Johnston <[email protected]>
Cc: pgsql-hackers <[email protected]>
Cc: Ashutosh Bapat <[email protected]>
Cc: Jelte Fennema-Nio <[email protected]>
Subject: Re: how to gate experimental features (SQL/PGQ)
Date: Wed, 14 Jan 2026 10:22:23 -0800
Message-ID: <CAOYmi+n3sDhuS6m-Y=iFCUM2p1TUd3kMbQxvygGPFdAzJLegyQ@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<cwthrfgp2foh64aylx6wkcl2v2543qlqxztgkg6pwscqum7jw7@oyf57d3x46fu>
	<CAOYmi+mAYpUZdxjc6pd-iW+uk4ShbLatAV-KhbDJR+xcCBQL2w@mail.gmail.com>
	<[email protected]>

On Tue, Jan 13, 2026 at 9:24 AM Tom Lane <[email protected]> wrote:
> 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.

Makes sense.

If an experiment had so many changes to the parser that it'd be worth
the (potentially considerable) effort, maybe we could ship just two
parser versions (a base, and a draft) and maintain the diff between
them with some [handwavy magic] preprocessing? Probably too early in
the thread to get into the weeds that much, but the ability to ship a
minor-version parser improvement for a draft feature, without putting
the supported core at risk, seems like it could be worth some amount
of maintenance cost.

> This seems workable for some kinds of features and less so for others.
> As an example, forcing initdb post-release seems like a nonstarter
> even for "experimental" features, so anything that affects initial
> catalog contents is still going to be a problem.

Yeah, a surprise initdb (even if well-documented) seems like it might
discourage use of any experimental features, if it's not easy to tell
which experiments might lock you into future pain.

--Jacob






view thread (2+ messages)

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: how to gate experimental features (SQL/PGQ)
  In-Reply-To: <CAOYmi+n3sDhuS6m-Y=iFCUM2p1TUd3kMbQxvygGPFdAzJLegyQ@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox