On Fri, Dec 18, 2015 at 9:52 AM, Robert Treat <r...@xzilla.net> wrote: > On Thu, Dec 17, 2015 at 4:31 PM, Robert Haas <robertmh...@gmail.com> wrote: >> On Wed, Dec 16, 2015 at 10:48 PM, Jim Nasby <jim.na...@bluetreble.com> wrote: >>> 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). >> >> Not to me. GUCs like array_nulls don't really cost much - there is no >> reason to be in a hurry about removing them that I can see. >> > > Perhaps not with rock solid consistency, but we've certainly used the > argument of the "not a major major version release" to shoot down > introducing incompatible features / improvements (protocol changes > come to mind), which further lends credence to Jim's point about > people expecting backwards incompatible breakage to be in a major > major version changes.
My memory is that Tom usually argues pretty vigorously against the idea that there's anything special about a first-digit bump in terms of incompatibilities. But your memory may have a longer reach than mine. > Given the overhead from a development standpoint is low, whats the > better user experience: delay removal for as long as possible (~10 > years) to narrow the likely of people being affected, or make such > changes as visible as possible (~6+ years) so that people have clear > expectations / lines of demarcation? IMHO, it's almost hopeless to expect users to prepare for incompatible changes we want to make. When we try to force it, as we did with standard_conforming_strings or the 8.3-vintage casting changes, we cause a lot of user pain and that's about it. People don't say "ah, these changes are coming, I need to adjust my app to be safe in this new world"; instead, they say "crap, I can't upgrade, PostgreSQL hackers suck". We spend our days and nights worrying about this stuff, but real users don't. They just got knocked over when the change hits. Or the people who understand that the problem is coming are in a different group than the people who have to fix it, so it doesn't get fixed. Or whatever. 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. Ideally they'd upgrade about every 4 years, so that they get off the oldest supported release before it actually drops out of support, but for various reasons it often takes longer than that, and their current version is out of support before they get around to upgrading. We can wag our tongues and cluck at those people, but when we're quick to pull the trigger on removing backward compatibility hacks, we actually make the problem worse, not better. Now people stay on the old versions even longer, because they can't upgrade until they fix their app. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
