On Mon, Aug 29, 2016 at 6:37 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Mon, Aug 29, 2016 at 7:12 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Craig Ringer <cr...@2ndquadrant.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/
