Re: 10.0
Jim Nasby <jim.nasby@bluetreble.com>
From: Jim Nasby <Jim.Nasby@BlueTreble.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Merlin Moncure <mmoncure@gmail.com>, Craig Ringer <craig@2ndquadrant.com>, 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>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2016-06-14T20:05:01Z
Lists: pgsql-hackers
On 6/14/16 3:01 PM, Robert Haas wrote: >> 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. > This seems kind of silly, because anybody who is writing code that > might have to run against an existing version of the database won't be > able to use it. The one thing that absolutely has to be cross-version > is the method of determining which version you're running against. We're talking about a function that doesn't currently exist anyway. So no matter what, you won't be able to use it if you're interested in <10.0 (or <9.6 if we went with one of the other proposals). Unless folks were thinking this is something that would be backpatched? -- 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