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
