Closed afig closed 6 years ago
Postgres has changed the numbering scheme for versions. Here is a link to the relevant docs: https://www.postgresql.org/docs/10/static/libpq-status.html#LIBPQ-PQSERVERVERSION
Here is an excerpt of the relevant portion from the link. The "this function" in the text refers to function PQserverVersion
which is the C-equivalent of the server setting server_version_num
:
Applications might use this function to determine the version of the database server they are connected to. The result is formed by multiplying the server's major version number by 10000 and adding the minor version number. For example, version 10.1 will be returned as 100001, and version 11.0 will be returned as 110000. Zero is returned if the connection is bad.
Prior to major version 10, PostgreSQL used three-part version numbers in which the first two parts together represented the major version. For those versions, PQserverVersion uses two digits for each part; for example version 9.1.5 will be returned as 90105, and version 9.2.0 will be returned as 90200.
Therefore, for purposes of determining feature compatibility, applications should divide the result of PQserverVersion by 100 not 10000 to determine a logical major version number. In all release series, only the last two digits differ between minor releases (bug-fix releases).
The Postgres documentation related to getting version information, contains the following statement (emphasis mine):
The machine-readable
server_version_num
returns an integer containing a numerically sequential version number. As examples, for Postgres version 9.3.24, this number is90324
, for Postgres 9.6.10, it is90610
and for version 10.5,100005
.Currently in
addServerVersionComparersCore.sql
, we are usingserver_version
, rather than the recommendedserver_version_num
. As a matter of fact, the variability of the non-machine-readable version caused quite a few issues when getting PR 232 ready to merge. In the end, we ended up with more functionality than if we had gone with the more direct route (can optionally ignore minor versions and input version numbers as the standard x.y.z rather than xxyyzz).ClassDB should internally implement use of
server_version_num
to avoid the variability of theserver_version
string. Currently, if a distribution adds branding before the version number in the version string, our code will no longer function correctly (we already handle the possibility of there being branding after the version number). Our current internal functions should still take in x.x.x/x.x version numbers for convenience and to avoid having to make widespread API-breaking changes.