On 1/13/26 12:24, 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.
>
>> But overall, I think I'd rather work with an environment where we
>> occasionally say "hey, this clearly-labeled experimental feature was
>> not baked enough, pull it back now" as opposed to occasionally saying
>> "hey, we never got this one feature everyone wants because we'll never
>> be practically sure that it's 'right' enough without user testing".
>
> 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.
<snip>
> It might be better just to say that you only get to change
> experimental catalog entries once a year in major releases. (Slow
> progress is still better than no progress.)
+1
This seems like the best compromise. Overall I think we need a way to
make progress on big invasive features that need incremental rollout and
broad testing to get right. Moving forward while clearly designating at
least some of these as "experimental and subject to breaking changes
once every major release" is far better than never making progress at
all IMHO.
--
Joe Conway
PostgreSQL Contributors Team
Amazon Web Services: https://aws.amazon.com
