On Tue, Jun 14, 2016 at 4:13 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
> 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.
Right. It's the only way to handle things on the SQL level well,
that, and pg_settings approaches. In other words, there is no easier
way. I think it's pretty reasonable to assume there's a lot more code
interfacing with the database from SQL than from C.
merlin