Re: 10.0

On Tue, Jun 14, 2016 at 5:58 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:

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

​We could stand to be more explicit here. The docs for version() indicated
the server_version_num should be used for "machine processing".

The implied correct way to access the canonical server version is thus:

SELECT current_setting('server_version_num');

I'd say we should at least provide the above as an example; the reader can
find their way to Chapter 18.1 if they are curious about alternatives.

​On the topic of option "D" I'd be fine with fine with functions:
<version_major() : numeric> and <version_patch() : integer​>; but that is
independent of this discussion.

Option E: Give the DBA control. If they know they have one or more
mis-behaving applications but it is out their control to patch the code to
work properly they can change this supposedly human-readable output to
conform the historical x.y.z format. This would disabled by default.
Humans can easily interpret both versions so please save the comment about
not having GUCs that influence user-visible behavior. If your argument for
changing the format outright is "its for human consumption only" then
apparently this output should not be considered important enough to adhere
to that rule. Non-humans depending on its format are subject to our, or
the DBA's, whims.

David J.