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 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
