Re: 10.0

On Wed, Jun 15, 2016 at 9:38 AM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:

> On Tue, Jun 14, 2016 at 5:48 PM, David G. Johnston
> <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> > 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".
>
> 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.

David J.​