On Thu, Jun 2, 2016 at 6:40 AM, Tom Lane <t...@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.

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to