Re: scary patch contest

On Wed, Aug 26, 2026 at 10:11 AM Melanie Plageman
<melanieplageman(at)gmail(dot)com> wrote:
> And I am not arguing against releasing minimal viable versions of
> features. But I think that the design that ships should be one that we
> all agree is the right first step/minimal design and not what we've
> reduced the feature to to deal with a bunch of bugs and issues that
> came out post-commit and wouldn't have agreed was right had it been
> initially proposed.

+1.

> There are loads of things like this in Postgres. It doesn't mean we
> shouldn't tackle them. But it also doesn't mean we should reduce the
> bar for what goes into core. Being somewhat better than very buggy 3rd
> party solutions is not the bar for what goes into Postgres. Again, I'm
> not saying REPACK CONCURRENTLY falls into that bucket, just that I
> don't want this sentiment to be the consensus.

+1.

> Separately, I'm not against the idea of protecting features behind
> gucs that we aren't sure exactly how they will fare in the wild. But
> that is different than taking features we feel pretty sure have bugs
> and releasing them for people to just try them out. Those people can
> test master.

Exactly. If we revert anything from v19, we can either decide also
that it should get reverted from master, or that it can stay in master
and hopefully be in good shape to ship next time. It's not exactly a
coincidence that all of the features that have had all of these fixups
were committed quite close to feature freeze. If they'd been committed
on, say, August 26th of last year, there's a good chance that they
would have had most of the bugs flushed out by now. Stuff that's got
serious design flaws should maybe just be reverted everywhere and
retried some day after an appropriate amount of re-thinking, but stuff
that just needs more bug fixing could potentially stay in to
facilitate continued work and avoid thrashing the tree around. But
neither category of thing belongs in a released branch. We have plenty
of bugs to fix in code we don't already know to be buggy.

--
Robert Haas
EDB: http://www.enterprisedb.com