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