While compatibility with PG16 has been fixed in #1582, it's not entirely done yet: In Debian, when testing if upgrading libpq5 from 15 to 16 is safe, the problems fixed in #1582 reappear:
46s test_ssl_attribute (tests.test_connection.TestConnectionInfo.test_ssl_attribute) ... FAIL
46s test_ssl_in_use (tests.test_connection.TestConnectionInfo.test_ssl_in_use) ... ok
46s test_ssl_not_supported (tests.test_connection.TestConnectionInfo.test_ssl_not_supported) ... skipped 'skipped because libpq 150003'
https://ci.debian.net/data/autopkgtest/unstable/amd64/p/psycopg2/37551454/log.gz
This happens when the psycopg2 compiled against libpq5 15 is run with libpq5 16. @skip_after_libpq(16) does not trigger because it uses psycopg2.__libpq_version__ which is statically initialized:
if (0 > PyModule_AddIntConstant(module,
"__libpq_version__", PG_VERSION_NUM))
{ return -1; }
In short, this constant shouldn't be a constant, but be loaded at run time.
I tried replacing PG_VERSION_NUM with PQlibVersion(), but that does not seem to be enough, there are other places with more version numbers, and setup.py even redefines its own PG_VERSION _NUM at which point I gave up.
Could someone with more insight into which version number is supposed to mean what check what needs to be done to fix @skip_after_libpq(16) to look at the run-time libpq version? Thanks.
While compatibility with PG16 has been fixed in #1582, it's not entirely done yet: In Debian, when testing if upgrading libpq5 from 15 to 16 is safe, the problems fixed in #1582 reappear:
https://ci.debian.net/data/autopkgtest/unstable/amd64/p/psycopg2/37551454/log.gz
This happens when the psycopg2 compiled against libpq5 15 is run with libpq5 16.
@skip_after_libpq(16)does not trigger because it usespsycopg2.__libpq_version__which is statically initialized:In short, this constant shouldn't be a constant, but be loaded at run time.
I tried replacing
PG_VERSION_NUMwithPQlibVersion(), but that does not seem to be enough, there are other places with more version numbers, and setup.py even redefines its own PG_VERSION _NUM at which point I gave up.Could someone with more insight into which version number is supposed to mean what check what needs to be done to fix
@skip_after_libpq(16)to look at the run-time libpq version? Thanks.