From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Remove array_nulls? |
Date: | 2015-12-15 06:26:35 |
Message-ID: | CAB7nPqTx-S4MCEdfQo4ExT+KG0WAyE+N4c8uUndxCqheJV74-A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2015-12-15 07:13:57 | Re: pgbench stats per script & other stuff |
Previous Message | Amit Langote | 2015-12-15 05:28:46 | Re: find_inheritance_children() and ALTER TABLE NO INHERIT |