On Tue, Dec 15, 2015 at 1:26 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Tue, Dec 15, 2015 at 2:57 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
>> On 12/11/15 2:57 PM, Tom Lane wrote:
>>> Jim Nasby <Jim.Nasby@BlueTreble.com> writes:
>>> Perhaps, but I'd like to have a less ad-hoc process about it. What's
>>> our policy for dropping backwards-compatibility GUCs? Are there any
>>> others that should be removed now as well?
>>
>>
>> Perhaps it should be tied to bumping the major version number, which I'm
>> guessing would happen next whenever we get parallel query execution. If we
>> do that, a reasonable policy might be that a compatability GUC lives across
>> no more than 1 major version bump (ie, we wouldn't remove something in 9.0
>> that was added in 8.4).
>
> Another possibility may be to link that with the 5-year maintenance
> window of community: a compatibility GUC is dropped in the following
> major release if the oldest stable version maintained is the one that
> introduced it. Just an idea.
Yeah, there's something to be said for that, although to be honest in
most cases I'd prefer to wait longer. I wonder about perhaps
planning to drop things after two lifecycles. That is, when the
release where the incompatibility was added goes out of support, we
don't do anything, but when the release that was current when it went
out of support is itself out of support, then we drop the GUC. For
example, 8.2 went EOL in December 2011, at which point the newest
release was 9.1. So when 9.1 is out of support, then we could drop
it; that's due to happen this September. So 9.6 (or 10.0, if we call
it that) could drop it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
