Re: scary patch contest

On 2026-08-26 We 10:11 AM, Melanie Plageman wrote:
> On Wed, Aug 26, 2026 at 4:01 AM Jakub Wartak
> <jakub(dot)wartak(at)enterprisedb(dot)com> wrote:
>> On Tue, Aug 25, 2026 at 9:29 PM Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>>> On 2026-08-25 Tu 2:54 PM, Robert Haas wrote:
>>>> On Tue, Aug 25, 2026 at 2:13 PM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
>>>>>> #2 has been cut back in scope enough that I don't think we would have accepted
>>>>>> the feature originally if it had been subject to those limitations, which IMHO
>>>>>> is a reasonable argument for a revert but also not conclusive.
>>>>> I don't think that is an argument for reverting, I think it's an argument for
>>>>> blocking progress by making perfect the enemy of good.
>>>> I'm not sure I understand what you're saying here. My guess is that
>>>> you're arguing that we should have been willing to take REPACK
>>>> CONCURRENTLY even if we'd known from the beginning that the
>>>> one-at-a-time-per-cluster restriction would have been necessary. I
>>>> would have argued against that, but perhaps I would have been wrong to
>>>> do so, and it's certainly fair if you feel otherwise.
>>>
>>> Given the unsatisfactory state of all the alternatives, I think it is
>>> still worth having, modulo any remaining bugs.
>> Very well said, +1.
> I disagree with this. The unsatisfactory state of alternatives is not
> a reason to ship code in core Postgres that we don't feel is ready.
> Something can be worth having but not be ready. And this discussion
> isn't about whether or not the feature is a good idea but rather about
> whether the feature should be shipped to users now.
>
> I am not arguing that REPACK CONCURRENTLY should be reverted. But I
> wanted to weigh in on this lest we think there is broad consensus that
> really wanting a feature is sufficient grounds for shipping it.
>
> 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.

I didn't mean to say that the process has been satisfactory. I was
merely commenting on where we are now, which I think is strictly better
than where we would be  without it, albeit that is has limitations we'd
much rather not have.

If we thought this was a barrier to getting to an implementation without
those limitations then there would be a good case for reversion.

I agree with your third paragraph, that states the ideal process. Sadly,
things sometime get a bit messier than that.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com