Re: 10.0

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Mark Dilger <hornschnorter(at)gmail(dot)com>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Dave Page <dpage(at)pgadmin(dot)org>, Thom Brown <thom(at)linux(dot)com>, David Fetter <david(at)fetter(dot)org>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: 10.0
Date: 2016-06-20 18:22:42
Message-ID: CAKFQuwbf-px4ozSgw7Ao+foVPdZiCgVjTgYXRLYhmwOQqR85Tg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jun 20, 2016 at 1:48 PM, Mark Dilger <hornschnorter(at)gmail(dot)com>
wrote:

>
> > On Jun 20, 2016, at 9:38 AM, David G. Johnston <
> david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> >
> > On Mon, Jun 20, 2016 at 12:28 PM, Mark Dilger <hornschnorter(at)gmail(dot)com>
> wrote:
> >
> > > On Jun 20, 2016, at 8:53 AM, Mark Dilger <hornschnorter(at)gmail(dot)com>
> wrote:
> > >
> > >
> > > This is not a plea for keeping the three part versioning system. It's
> just
> > > a plea not to have a 2 part versioning system masquerading as a three
> > > part versioning system, or vice versa.
> >
> > To clarify my concern, I never want to have to write code like this:
> >
> > CASE WHEN pg_version eq '11.1' OR pg_version eq '11.0.1' THEN
> foo()
> > WHEN pg_version eq '11.2' OR pg_version eq '11.0.2'
> THEN bar()
> > ....
> > or
> >
> > if (0 == strcmp(pg_version_string, "11.1") || 0 ==
> strcmp(pg_version_string, "11.0.1"))
> > foo();
> > else if (0 == strcmp(pg_version_string, "11.2") || 0 ==
> strcmp(pg_version_string, "11.0.2"))
> > bar();
> >
> > either in sql, perl, c, java, or anywhere else. As soon as you have two
> different
> > formats for the version string, you get into this hell. Yeah, ok, you
> may have
> > a sql level function for this, but I'm thinking about applications
> somewhat removed
> > from a direct connection to the database, where you can't be sure which
> format
> > you'll be handed.
> >
> > Now you argue for keeping the middle number on pure compatibility
> grounds.​..
>
> I am not arguing for that. I'm arguing against having two different
> versions of the
> same thing. If you go with a two part versioning scheme that is sometimes
> written as a
> three part versioning scheme, you make every bit of code that deals with
> it from now on
> have to deal with both possible versions in order to be robust.
>
> My preference is to have a three part versioning scheme where all three
> parts have
> different purposes. But since the community seems to have no interest in
> that, and
> have largely (if not universally) rejected that idea, I'm falling back to
> merely arguing
> that if we're going to have a two part versioning system, we should do
> that everywhere,
> and if we can't do that everywhere, then we should do that nowhere.
>
> You appear to be arguing that we should have a versioning scheme that is
> sometimes
> two parts, and sometimes three parts, but when three parts, always make
> the middle
> number zero. The part of that which bothers me most is not the "always
> zero" part. It's
> the "sometimes two parts, sometimes three parts" part
>

​The machine representation of the version number is 6 digits without any
punctuation.

The human representation for version numbers >= 10 is two integers
separated using a full-stop/period/decimal "."

You would never write 10.0.2 instead of 10.2 just like you'd never write
1002 instead of 100002

​You only have to do more than one thing if you are using the wrong
representation and are trying to be robust. While I understand that some
people may indeed be doing that or otherwise stuck in that unfortunate
circumstance accommodating their needs amounts to nothing other than
maintaining compatibility for unsupported usage. I'll admit we probably
could have been more explicit on what we do consider proper usage - which
is why I have at least some sympathy for the position.

David J.

In response to

  • Re: 10.0 at 2016-06-20 17:48:57 from Mark Dilger

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2016-06-20 18:30:26 Re: 10.0
Previous Message Mark Dilger 2016-06-20 18:14:44 Re: 10.0