On 6/14/16 3:56 PM, Tom Lane wrote:
> Jim Nasby <Jim.Nasby@BlueTreble.com> writes:
>> On 6/14/16 3:01 PM, Robert Haas wrote:
>>> 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.
>
> Huh? We're talking about PQserverVersion(), comparisons to PG_VERSION_NUM,
> and related APIs. Those most certainly exist now, and trying to supplant
> them seems like a giant waste of time.
>
> On the other hand, parsing fields out of version() mechanically has been
> deprecated for as long as those other APIs have existed (which is since
> 8.0 or so). version() is only meant for human consumption, so I see no
> reason it shouldn't just start returning "10.0", "10.1", etc. If that
> breaks anyone's code, well, they should have switched to one of the
> easier methods years ago.
The original post was:
> IF substring(version() FROM $q$([0-9]+\.[0-9]+)$q$)::NUMERIC >= 9.3
and \df *version* on my HEAD doesn't show any other options.
--
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