On Fri, Sep 11, 2026 at 12:19:15AM -0400, Robert Haas wrote:
> 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.

To clarify, that text was me offering Andrew a new option, not suggesting that
he has any new duty.

> > 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 defects are the reason not to ship this implementation.  One of those
defects, the inability to restore in dependency order, cannot be fixed without
redesigning the current SQL-facing API.  That is the reason not to ship this
design.  See my original post of this thread for details.


Reply via email to