On Fri, Dec 18, 2015 at 11:08 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> 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.
I don't want to toot my own horn too much here, but I think parallel
query might be an appropriate milestone. If we don't get any more
than what we have now done for this release, well, no, probably not.
But what if we get the parallel join stuff I've posted and the work
David Rowley and Haribabu Kommi are doing on parallel aggregate done?
At that point I think it starts to get pretty interesting. Sure,
there will be plenty of work left to do, but that's often true: 9.0
introduced streaming replication and Hot Standby, but they got a lot
more usable in 9.1.
> 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.
Right. If a particular backward-compatibility flag is preventing
important improvements, that's a good argument for phasing it out
sooner. But that's certainly not the case with array_nulls so, uh,
who cares?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
