On Tue, Jan 2, 2018 at 9:20 PM, Craig Ringer <cr...@2ndquadrant.com> wrote:
> Last time I tried to actually deploy packages that used --with-extra-version
> a variety of tools that talk to postgres broke because they choked when
> parsing the version. Including widely used ones like check_postgres.
I think there's likely a big difference between --with-extra-version='
(blah)' and --with-extra-version='blah', though. It does this:
if ($row->{version} !~ /((\d+\.?\d+)(\w+|\.\d+))/) {
add_unknown msg('invalid-query', $row->{version});
next;
}
my ($full,$version,$revision) = ($1,$2,$3||'?');
$revision =~ s/^\.//;
That being said, I'm starting to agree with you that exposing
server_version_num might be a good idea. Anybody who creates a
modified version of PostgreSQL -- and we have a license that allows
that -- wants some way to indicate their modified version. If you
change "PostgreSQL" in the version to anything else, or add additional
components to the version number, clients blow up and die. I'm
guessing that adding "(Aurora 4.5.2)" or "(Advanced Server 11.1)" or
whatever after the main version number, separated by a space, might
work better, but it's still vulnerable to misinterpretation by a
client that is sufficiently-picky about the contents of the version
string. Reporting a bare integer would fix that problem in a better
way, but of course only if client code is changed to use it, which we
have no way to enforce.
Well, we could enforce it if we broke SELECT version() outright, but
that approach would probably not attract many votes.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
