Re: Remove array_nulls?

Robert Haas wrote:
> On Fri, Dec 18, 2015 at 9:52 AM, Robert Treat <rob@xzilla.net> wrote:

> > 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.

We haven't made a lot of first-digit changes, and if I recall correctly
it has been mostly a matter of PR, based on sets of particular features,
rather than objective technical criteria (such as changes in backwards
compatibility or such).  For instance we changed from 7 to 8 mostly
because of adding the Windows port and PITR, and from 8 to 9 because of
replication -- you could think of those as major steering changes, with
large influence in what came afterwards.

I don't know what would be a good reason to change from 9 to 10, but
certainly we shouldn't do it just to remove a couple of GUCs -- much
less do it for no reason at all (which would be what "but 9.6 is too
close to 9.10 already" would boil down to.)  I sure hope we're gonna
find some good reason to do it before 9.10 actually comes around.

> > 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.

Agreed on this.  (As anecdote, I remember people relying on
add_missing_from, and never fixing the apps, until they absolutely had
no choice because the GUC was removed, even though I warned years in
advance.)

On the other hand, while I agree with you that we should strive to
maintain backwards compatible options for a long time, and that in this
particular case I see no reason not to wait a few more releases since it
doesn't hurt anything, I don't think we should make this an iron-clad
rule: I imagine there might be cases where there will be good reasons to
break it sooner than those 10 years if maintenance becomes a serious
problem otherwise.  We will need to discuss each case individually as it
comes up.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services