On Tue, May 17, 2016 at 12:45 AM, Craig Ringer <cr...@2ndquadrant.com> wrote: > On 14 May 2016 at 02:49, Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers