> On Wed, Jun 1, 2016 at 5:04 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> Probably not, but yes, I do want to reduce the commit load. I also
>> think that we essentially have a contract with our users to limit what
>> we back-patch to critical bug fixes and security fixes. When we don't
>> do that, people start asking to have individual fixes cherry-picked
>> instead of just upgrading, and that's not good. We may know that such
>> changes are low-risk, but that doesn't mean everyone else does.
I suggest that there's a more principled reason for refusing a back-patch
here, which is that we don't back-patch new features, only bug fixes.
This request is certainly not a bug fix. It's in support of a new feature
--- and one that's not even ours, but a third-party extension.
Considering that said extension isn't finished yet, it's hard to guess
whether this will be the only blocking factor preventing it from working
with older versions, but it might well be that there are other problems.
Also, even if it would work, the author would be reduced to saying things
like "it will work in 9.4, if it's 9.4.9 or later". Keeping track of that
level of detail is no fun either for the author or for users. It'd be
a lot simpler all around to just say "my spiffy new extension requires 9.6
or later".
In short, I'd vote for putting this change in HEAD, but I see no need to
back-patch.
regards, tom lane