DASSL / ClassDB

An open-source system to let students experiment with relational data
https://dassl.github.io/ClassDB/
Other
8 stars 2 forks source link

Server version comparison uses incorrect preset option (W) #263

Closed afig closed 6 years ago

afig commented 6 years ago

The Postgres documentation related to getting version information, contains the following statement (emphasis mine):

version returns a string describing the PostgreSQL server's version. You can also get this information from server_version or for a machine-readable version, server_version_num. Software developers should use server_version_num (available since 8.2) or PQserverVersion instead of parsing the text version.

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 is 90324, for Postgres 9.6.10, it is 90610 and for version 10.5, 100005.

Currently in addServerVersionComparersCore.sql, we are using server_version, rather than the recommended server_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 the server_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.

smurthys commented 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).