Re: 10.0

On Wed, Jun 15, 2016 at 8:59 AM, David G. Johnston
<david.g.johnston@gmail.com> wrote:
> On Wed, Jun 15, 2016 at 9:38 AM, Merlin Moncure <mmoncure@gmail.com> wrote:
>>
>> 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?
>
>
> Sleeping on it I too came to the conclusion that the GUC was largely an
> undesirable option.
>
> IIRC the plan is to have the machine version behave as if the middle number
> is present and always zero.  It would be (the?) one place that the
> historical behavior remains visible but it is impossible to have a totally
> clean break.
>
> Tom's comment back on May 14th (different thread) was that we'd basically
> redefine the minor portion to be 4-digits instead of 2.

That makes sense -- I'm good then.  Thanks for engaging

merlin