Re: [PATCH] Send numeric version to clients

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Craig Ringer <craig(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Abhijit Menon-Sen <abhijit(dot)menon-sen(at)2ndquadrant(dot)com>, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>
Subject: Re: [PATCH] Send numeric version to clients
Date: 2016-08-29 16:51:03
Message-ID: CABUevEyJ+cQzYHV5Rk=08AHMX8b77n65T2j2AVU_GX80OLXk8Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Aug 29, 2016 at 6:37 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Mon, Aug 29, 2016 at 7:12 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Craig Ringer <craig(at)2ndquadrant(dot)com> writes:
> >> The same sort of problems apply to network clients, but network
> >> clients don't currently get that option because we only send
> >> server_version on the wire in the startup packet. We don't send
> >> server_version_num.
> >
> >> It'll be immediately useful to have this since clients can test for
> >> it, use it if there, and fall back to their old version parsing code
> >> if there's no server_version_num.
> >
> > I think that this would merely create an attractive nuisance: people
> > would be very likely to omit the "fallback" code and thereby build
> > clients that fail for no very good reason on pre-v10 servers. As a
> > demonstration that that's not a hypothetical risk, I assert that
> > that's exactly what you propose telling them to do:
> >
> >> Version 10.0 is the perfect time to
> >> do this since many clients will need to update their version handling
> >> anyway, and we can just tell them to use server_version_num now.
>
> You know, I've kind of been on Craig's side of this running dispute up
> until now, but I have to admit that this seems like an awfully good
> argument. The fact is that nobody's going to be able to rely on
> server_version_num until 9.6 is long gone - which doesn't mean late
> 2021, when official community support will end, but several years
> after that, when most everyone has actually stopped using it. Of
> course, by that time, assuming we don't backpedal on our decision to
> go with this new versioning scheme, three part version numbers will be
> equally dead and gone, and it's actually a lot easier to extract the
> major version number from the new format than the old. For example,
> you can just apply atoi() to it:
>
> if (atoi(server_version) < 12)
> fprintf(stderr, "server is ancient, some features will not work\n");
>
> That wouldn't be nearly good enough with three part version numbers
> because you need the second component, as well. But all that's going
> away now. If you need a port to some other language:
>
> In Perl, you can test int($server_version).
> In Javascript, you can test parseInt(server_version).
> In Python, it's a bit harder. But int(re.sub(r'[^\d+]+', '',
> server_version)) seems to work.
>

FWIW, a slightly cleaner but still somewhat meh way would be
int(float(server_version)). No need to mess around with regexps and extra
imports.

Long story short, I kind of agree that it might have been better to
> expose server_version_num rather than server_version in the beginning,
> but I'm not sure that it really helps anybody now, especially given
> our decision to simplify the version number format going forward.
>

Yeah, that's a strong point.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2016-08-29 16:51:25 Re: Renaming of pg_xlog and pg_clog
Previous Message Robert Haas 2016-08-29 16:39:30 Re: [COMMITTERS] pgsql: Change the way that LWLocks for extensions are allocated.