On 5 August 2016 at 04:31, Tom Lane <t...@sss.pgh.pa.us> wrote:
> In short: if we'd done it that way all along, it would've been nice. But encouraging people to change horses now isn't really going to > make things better. What is far more likely to happen, if we were > to do that, is that people will make clients that gratuitously fail > on old server versions because they didn't bother to support or test > for the case that the server doesn't send server_version_num. > Yup, if someone's writing a completely new client or bypassing their database driver's version detection. But the same argument would've applied when the server_version_num GUC was added in the first place. The world didn't end then, and it won't now. Yes, it'll add a small cost to the startup packet, but that's it. It should've been done when server_version_num was added in the first place and it should be done now. Small variation in one-off packet size is pretty unimportant anyway TBH, since it's latency and roundtrip costs and that hurt us. You don't really want to encourage multiple ways of identifying which > software version you're dealing with. That way madness lies. > > Yet we have a server_version_num GUC. Because it's useful and people benefited from it. It's a pain in the butt having 9.4beta, etc and having to deal with those. I like to think we think in the long term here. The same arguments you make against adding server_version_num as GUC_REPORT apply to pretty much every improvement that exposes any kind of UI, including new SQL. Users won't be able to use it for ages, it'll break apps that connect to older servers if they use the new feature, etc etc. Lets just add it. It should've been there in the first place, it was an oversight not to add it when initially adding server_version_num, and it should be fixed. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
