Postgres version string from ubuntu still causing errors [BugFix]

[guionardo]

When the PosgreSQL version has values like this: "12.4 (Debian 12.4-1.pgdg100+1)", a exception is raised in versionstring.split.
I added some normalization code to avoid this.

I don't have permission to contribute here with PR. So this is the patch to fix this.

def assure_version(v:str)->str:
	'''Assure the version from postgres is in 99.99[.99] format'''
	import re

	for match in re.finditer("(\d{1,2}.\d{1,2})(\.\d{1,2})?", v):
		return match.group()
	return v

Change the line 19 of postgresql/versionstring.py
from

	v = vstr.strip().split('.')

to

	v = assure_version(vstr).strip().split('.')

[jwp]

Your efforts are appreciated, however, I believe debian offers a py-postgresql package handling their special case.

Supporting such variations in the version string and the protocol is not within the scope of the project. If such compensation is desired, you will, unfortunately, need to manage a patched distribution yourself. (A runtime patch is also possible)

You may also want to consider using: https://www.postgresql.org/download/linux/debian/
I suspect apt.postgresql.org has managed to avoid modifying the version.

Future versions (py-postgresql) may make this a non-issue. Presumably, we can drop support for 8.5 and defer version parsing, but applications needing to switch on server versions would still need a patched variant to handle debian's case.

[EdTorbett]

I've just encountered this same issue and don't see the above as a suitable resolution to this issue. Firstly, I am connecting to the database remotely and from a different operating system, so cannot rely on an OS-specific package release to resolve the issue. Secondly, no other client library gives the same error when connecting to the same database. If the above patch resolves this issue, why reject it?

[jwp]

In the short term, I think the runtime patch is something like:

import postgresql.versionstring as vs
def parse_debian_compat(vstr, _split=vs.split):
    return _split(vstr.split()[0])
vs.split = parse_debian_compat

Didn't test, so you might need to adjust it. Be sure to run that before doing other postgresql.* imports.

[jwp]

In the long term, I would advise not using a postgresql package that modifies that particular version string.
I suspect apt.postgresql.org will work. https://www.postgresql.org/download/linux/debian/

While other drivers connect successfully, applications that choose to switch on the version may be broken as well.
py-postgresql is revealing a symptom. The modification of that particular version string only serves to add risk.

On the py-postgresql side, the best that can be done is an exception trap defaulting the version.
Handling debian's (or other's) special case is simply out of scope. The only reason that this is even considerable is due to the possibility that a PostgreSQL fork or PQ server could, reasonably, make the mistake of omitting or adjusting this string substantially.

However, this driver is only tested against builds of source releases made by postgresql.org. If you're using it to connect to something that is not PostgreSQL, you will need to test it and likely make modifications to compensate.

[c7hm4r]

@jwp Why do you think that it is part of PostgreSQL’s specification that there must not be spaces in the preset option server_version? I could not find that this assumption is being made in the PostgreSQL project, neither officially (docs1, docs2) nor internally (source code). The source code of PostgreSQL seems to only assume that the version string starts with an integer. Or is your goal to just support a subset of PostgreSQL?

[jwp]

I'm not interested in debating this further. I have been quite clear about my position. If you find this unacceptable, I recommend that you take your own advice and use another driver (#113).

[c7hm4r]

Sorry, was just fairly frustrating when I tried to get a software building on this library to run and then stumbled over discussions over spaces in version strings. Am 11.03.21 um 22:29 schrieb James William Pye:

…

I'm not interested in debating this further. I have been quite clear about my position. If you find this unacceptable, I recommend that you take your own advice and use another driver (#113 <#113>). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#105 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPB6GNLTRFTX4VOTZKGGJDTDEY35ANCNFSM4SYLC6XA>.