Re: Remove array_nulls?

On 12/16/15 6:01 PM, Robert Haas wrote:
> On Tue, Dec 15, 2015 at 1:26 AM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
>> On Tue, Dec 15, 2015 at 2:57 AM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> wrote:
>>> On 12/11/15 2:57 PM, Tom Lane wrote:
>>>> Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)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.

IIUC, that means supporting backwards compat. GUCs for 10 years, which
seems a bit excessive. Granted, that's about the worse-case scenario for
what I proposed (ie, we'd still be supporting 8.0 stuff right now).

The reason I thought of tying it to "major major" release is just
because those generate even more notice and attract more users than
normal, so it'd be nice to clean house before doing one. Perhaps I'm
just introducing complexity that there's no need for.

If we don't want to tie "major major" number, then I think we should
just go with the normal support cycle.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com