Robert Haas <robertmh...@gmail.com> writes:
> My experience is that it is very common for users to upgrade across a
> whole series of releases at the same time. People don't upgrade from
> 8.3 to 8.4 and then to 9.0, or even from 8.3 to 9.0 to 9.2. I mean,
> some do. But people doing things like 8.2 -> 9.3 is not that
> uncommon, at least in my experience with EnterpriseDB customers.
> That's why we support releases for five full years, right? So that
> people don't necessarily have to upgrade more than about that often.
Yeah. For a recent example, see yesterday's thread with someone inquiring
about known bugs in 8.1 ... and they did not sound like they had any
intention of getting off that soon. But when they do, they're going to
have eight or ten years' worth of incompatibilities to deal with.
I did a quick troll through the commit log looking for previous cases
where we have removed backwards-compatibility GUCs. I could find only
two:
commit ab61df9e527dcedbd3bbefbcb8b634b0b72f2ad5
Author: Tom Lane <t...@sss.pgh.pa.us>
Date: Wed Oct 21 20:38:58 2009 +0000
Remove regex_flavor GUC, so that regular expressions are always "advanced"
style by default. Per discussion, there seems to be hardly anything that
really relies on being able to change the regex flavor, so the ability to
select it via embedded options ought to be enough for any stragglers.
Also, if we didn't remove the GUC, we'd really be morally obligated to
mark the regex functions non-immutable, which'd possibly create performance
issues.
commit 289e2905c82fc37f8b82b088bb823742aad4bb68
Author: Tom Lane <t...@sss.pgh.pa.us>
Date: Wed Oct 21 20:22:38 2009 +0000
Remove add_missing_from GUC and associated parser support for "implicit
RTEs".
Per recent discussion, add_missing_from has been deprecated for long enough
to
consider removing, and it's getting in the way of planned parser
refactoring.
The system now always behaves as though add_missing_from were OFF.
So in both those cases, there was an active reason to remove the GUC,
not just "it seems like this is too old for anyone to want it anymore".
Also worthy of remark is that add_missing_from and regex_flavor were both
added in 2003, so their useful lifespan was a lot shorter than what's
being suggested in this thread.
Not entirely sure what to make of this. It occurs to me that the "it
breaks immutability" argument might apply to array_nulls, though I've
not done any legwork to confirm or disprove that. If it doesn't apply,
though, I'm leaning to the position that there's no reason to remove
array_nulls.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
