Re: 10.0

On Tue, May 17, 2016 at 12:45 AM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
> On 14 May 2016 at 02:49, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>> * This year's major release will be 9.6.0, with minor updates 9.6.1,
>> 9.6.2, etc. It's too late to do otherwise for this release cycle.
>>
>> * Next year's major release will be 10.0, with minor updates 10.1,
>> 10.2, etc.
>>
>> * The year after, 11.0. Etc cetera.
>>
>
> Yes. Please!
>
> I get tired of explaining to people that PostgreSQL "9.x" isn't a thing,
> that yes, 9.3 and 9.4 really _do_ have incompatible data directories and
> replication protocols, and that when the docs say "major version" they don't
> mean "major version as you might actually expect" but "first two version
> number parts".
>
> Lets get rid of this user-baffling wart.

Agreed. What's been nagging me is what the impacts to users could be.
I just stumbled across some code that *could* have been broken, but by
sheer luck it's safe:

/* only postgres 9.3+ supports row count from 'COPY' */
IF substring(version() FROM $q$([0-9]+\.[0-9]+)$q$)::NUMERIC >= 9.3
THEN
GET DIAGNOSTICS _RowCount = ROW_COUNT;
ELSE
_RowCount := (LineCount(_ScratchFileName,
(SELECT WorkFolder FROM CDSControl)))::BIGINT - 1;
END IF;

LineCount() is a pl/sh wrapper to 'wc -l' that supports this wrapper
to COPY so that it always gives a count of rows loaded. I guess this
is a pretty hacky way of doing version checks inside of SQL but I
suppose changing the structure of the version number might break
similar approaches to parsing the string. This regex would in fact
continue to work properly, but it did raise some alarm bells.

Looking ahad, IMO we could:

A) make a variant of version() that returns major/minor/bugfix as
separate fields with minor being set to 0 for all released versions
10.0 and beyond. We could then add a NOTE to the version function and
other places suggesting to use that instead for 9.6.

B) Preserve x.y.z as returned by version() and show server_version for
those usages only, with 'y' being always 0 for 10.0 and beyond. For
all other purposes (marketing/documentation/etc) that structure would
*not* be preserved, and we would put notes in the documentation
describing why the extra digit is there.

C) Do neither A or B, and let our users discover such issues on their own.

merlin