On 1/13/26 12:24, Tom Lane wrote:
Jacob Champion <[email protected]> writes:
On Tue, Jan 13, 2026 at 7:17 AM Andres Freund <[email protected]> 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
