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