Re: 10.0
От | Jim Nasby |
---|---|
Тема | Re: 10.0 |
Дата | |
Msg-id | 0e0a80db-2c5d-fd50-33d8-2ec92d326c6e@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: 10.0 (Merlin Moncure <mmoncure@gmail.com>) |
Ответы |
Re: 10.0
Re: 10.0 |
Список | 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
В списке pgsql-hackers по дате отправления: