On Sat, May 19, 2018 at 4:41 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > It may be that this fix is simple and safe enough that the risk/reward > tradeoff favors back-patching, but I think you have to argue it as a > favorable tradeoff rather than just saying "this isn't per standard". > Consider: if Andrew had completely rewritten gram.y to get the same > visible effect, would you think that was back-patchable?
I strongly agree with the general principle that back-patching a bug fix needs to have a benefit that outweighs its cost. There have been cases where we chose to not back-patch an unambiguous bug fix even though it was clear that incorrect user-visible behavior remained. Conversely, there have been cases where we back-patched a commit that was originally introduced as a performance feature. Whether or not Andrew's patch is formally classified as a bug fix is subjective. I'm inclined to accept it as a bug fix, but I also think that it shouldn't matter very much. The practical implication is that I don't think it's completely out of the question to back-patch, but AFAICT nobody else thinks it's out of the question anyway. Why bother debating something that's inconsequential? FWIW, I am neutral on the important question of whether or not this patch should actually be back-patched. -- Peter Geoghegan