On Sat, May 19, 2018 at 4:41 PM, Tom Lane <tgl@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
