On Fri, Jun 19, 2020 at 3:27 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Anyway, as I write this I'm kind of talking myself into the position > that we should indeed back-patch this. The apparent stability > benefits of not doing so may be illusory, and if we back-patch then > at least we get to document that there's a change. But an argument > could be made in the other direction too.
It's really unclear to me why we should back-patch this into already-released branches. I grant your point that perhaps few people will notice, and also that this might happen at some point the change will be forced upon us. Nonetheless, we bill our back-branches as being stable, which seems inconsistent with forcing a potentially breaking change into them without a clear and pressing need. If you commit this patch to master and v13, no already-release branches will be affected immediately, and it's conceivable that some or even all of the older branches will age out before the issue is forced. That would be all to the good. And even if the issue is forced sooner rather than later, how much do we really lose by waiting until we have that problem in front of us? I'm not in a position to judge how much additional maintenance overhead would be imposed by not back-patching this at once, so if you tell me that it's an intolerable burden, I can't really argue with that. But if it's possible to take a wait-and-see attitude for the time being, so much the better. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
