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