On Thu, Jun 2, 2016 at 6:40 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
Yes, that's not a bug fix. I agree on that.
> 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.
The extension in this case is for 9.4, for a product yet to be
released that is now on 9.4.8, so I don't care much about the support
grid here to be honest.
> It'd be a lot simpler all around to just say "my spiffy new extension requires 9.6
> or later".
Well, that's the only factor as far as I saw that prevented me to use
this extension on Windows. But I won't fight your might regarding a
backpatch, wearing the burden of a custom patch applied to miscadmin.h
for REL9_4_STABLE is not huge: this code never changes.
> In short, I'd vote for putting this change in HEAD, but I see no need to
> back-patch.
OK, fine for me.
--
Michael