On 12/16/15 6:01 PM, Robert Haas wrote:
On Tue, Dec 15, 2015 at 1:26 AM, Michael Paquier
<michael.paqu...@gmail.com> wrote:
On Tue, Dec 15, 2015 at 2:57 AM, Jim Nasby <jim.na...@bluetreble.com> wrote:
On 12/11/15 2:57 PM, Tom Lane wrote:
Jim Nasby <jim.na...@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.
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
