Re: Remove array_nulls?

On Fri, Dec 18, 2015 at 9:52 AM, Robert Treat <rob(at)xzilla(dot)net> wrote:
> On Thu, Dec 17, 2015 at 4:31 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Wed, Dec 16, 2015 at 10:48 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)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