On Tue, Jun 14, 2016 at 4:13 PM, Jim Nasby <jim.na...@bluetreble.com> wrote:
> On 6/14/16 3:56 PM, Tom Lane wrote:
>> Jim Nasby <jim.na...@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
>> 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.


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to