On Tue, Jun 15, 2021 at 02:32:11PM -0700, Peter Geoghegan wrote:
> What I had in mind was this: a committer adopting the feature
> themselves. The committer would be morally obligated to maintain the
> feature on an ongoing basis, just as if they were the original
> committer. This seems like the only sensible way of resolving this
> issue once and for all.
>
> If it really is incredibly important that we keep this feature, or one
> like it, then I have to imagine that somebody will step forward --
> there is still ample opportunity. But if nobody steps forward, I'll be
> forced to conclude that perhaps it wasn't quite as important as I
> first thought.
Hackers are rather wise, but the variety of PostgreSQL use is enormous. We
see that, among other ways, when regression fixes spike in each vN.1. The
$SUBJECT feature was born in response to a user experience; a lack of hacker
interest doesn't invalidate that user experience. We face these competing
interests, at least:
1) Some users want the feature kept so their application can use a certain
pattern of long-running, snapshot-bearing transactions.
2) (a) Some hackers want the feature gone so they can implement changes
without making those changes cooperate with this feature. (b) Bugs in this
feature make such cooperation materially harder.
3) Some users want the feature gone because (2) is slowing the progress of
features they do want.
4) Some users want the feature kept because they don't use it but will worry
what else is vulnerable to removal. PostgreSQL has infrequent history of
removing released features. Normally, PostgreSQL lets some bugs languish
indefinitely, e.g. in
https://wiki.postgresql.org/wiki/PostgreSQL_13_Open_Items#Live_issues
5) Some users want the feature gone because they try it, find a bug, and
regret trying it or fear trying other features.
A hacker adopting the feature would be aiming to reduce (2)(b) to zero,
essentially. What other interests are relevant?