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.
It strikes me that we do have a mechanism that could be used to cope
with catalog changes, which is to package the new catalog objects as
an extension. Then ALTER EXTENSION UPDATE could be used to migrate
from FooBar Draft-2 to Draft-4. But the tricky bit would be to
replace the extension with in-core objects once we decide it's
completely baked. Our previous attempts to do that sort of thing
have been painful. 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.)
regards, tom lane
