Re: 10.0

Jim Nasby <jim.nasby@bluetreble.com>

From: Jim Nasby <Jim.Nasby@BlueTreble.com>
To: Merlin Moncure <mmoncure@gmail.com>, Craig Ringer <craig@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Alvaro Herrera <alvherre@2ndquadrant.com>, Josh berkus <josh@agliodbs.com>, David Fetter <david@fetter.org>, Thom Brown <thom@linux.com>, Dave Page <dpage@pgadmin.org>, Robert Haas <robertmhaas@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2016-06-14T19:46:19Z
Lists: pgsql-hackers
On 6/13/16 2:12 PM, Merlin Moncure wrote:
> 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.

D) Add a version function to 10.0 that returns both parts separately.

My vote is D. Parsing version() output is a wart, but coming out with a 
split output version of that in 9.6 that still has to support 3 numbers 
would also be a wart. We've lived with the parsing wart this long, so 
lets just add an explicit output version to 10.0.

Any ideas on naming for such a function? version_detail()? I suppose 
while we're at this we might as well provide the compile details as well.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)   mobile: 512-569-9461