On Tue, Jun 15, 2021 at 11:24 PM Noah Misch <n...@leadboat.com> wrote: > When I say "some hackers", I don't mean that specific people think such > thoughts right now. I'm saying that the expected cost of future cooperation > with the feature is nonzero, and bugs in the feature raise that cost.
I see. > > > A hacker adopting the feature would be aiming to reduce (2)(b) to zero, > > > essentially. What other interests are relevant? > > > > The code simply isn't up to snuff. If the code was in a niche contrib > > module then maybe it would be okay to let this slide. But the fact is > > that it touches critical parts of the system. This cannot be allowed > > to drag on forever. It's as simple as that. > > Even if we were to stipulate that this feature "isn't up to snuff", purging > PostgreSQL of substandard features may or may not add sufficient value to > compensate for (1) and (4). I'm more concerned about 1 (compatibility) than about 4 (perception that we deprecate things when we shouldn't), FWIW. It's not that this is a substandard feature in the same way that (say) contrib/ISN is a substandard feature -- it's not about the quality level per se. Nor is it the absolute number of bugs. The real issue is that this is a substandard feature that affects crucial areas of the system. Strategically important things that we really cannot afford to break. -- Peter Geoghegan
