Re: 10.0

On Tue, Jun 14, 2016 at 5:48 PM, David G. Johnston
<david.g.johnston@gmail.com> wrote:
> On Tue, Jun 14, 2016 at 5:58 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
>>
>> 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.
>
>
> We could stand to be more explicit here.  The docs for version() indicated
> the server_version_num should be used for "machine processing".

whoop! I didn't know about that setting.  I guess it dismantles a lot
of the case for more aggressive action.  That said, maybe it's a good
idea to construct the versioning change so that 10.x releases have a
server_version_num > 9.x releases and leave the other functions alone
(assuming that wasn't already the plan).

> 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.

Nah -- my argument could be restated as "I wasn't aware of the machine
variant of the version #".  Do you think it's a good idea to have the
machine version number be 100000 for version 10.0?  What would 10.1
be?  100100 or 100001?