On Thu, Sep 10, 2026 at 12:00 AM Noah Misch <[email protected]> wrote: > Going forward, feel free to add me to the To: line of a mailing list post and > explicitly ask me for my guess about the project's overall prognosis, likely > ways of failing, etc. My guess may be brief and/or wrong, but I'll provide > one.
I don't think this is how this mailing list works. The volume is overwhelming for me, too, but patch authors aren't obliged to cc anyone specifially. > When it's four months after feature freeze and I find non-subtle, unreported > defects in the feature, the development process wasn't adequate for the > subject matter. To be transparent, observing this outcome changed my view of > code duplication. Duplication was always a smell, but it seemed like a > plausible compromise tactic in 2025. Now I find the duplication gave wrong > code too much place to hide. I think we would do well to confine all of our present conversations, insofar as it is possible to do so, to whether any given feature contains defects incompatible with shipping it. The desirability of this particular feature is, as Andrew says, something that would have been better litigated six or more months ago. Granted, we're all overwhelmed, and that makes it more understandable that people who had concerns about desirability did not raise them at the time, but we will not succeed in producing awesome software by forcing last-minute reverts because we've changed our mind about whether the feature is a good idea in principle. There's more than enough to revert on the basis of whatever is broken in practice. That said, if this is coming out of v19 anyway, then IMHO it is fair game to reopen the question of whether we want it in v20. But if we're going to do that, we should hash that out now rather than in six months from now or twelve months from now. Personally, I have mixed feelings about this feature. On the one hand, I am sure it will get some use, and I have wanted it myself. On the other hand, it will get far less use, and far less testing, than the equivalent code in pg_dump, so it's more likely to have bugs now and in the future, and the fact that there's no reasonable way (at least, not that I can see) to handle version skew within a facility like this is a major disadvantage vs. pg_dump. Nevertheless, on balance, I'm unconvinced that there's sufficient reason to categorically block a sufficiently-well-implemented feature of this type. But not even the most desirable feature should remain in tree if the implementation isn't of sufficient quality. -- Robert Haas
