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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
