Trap Version Parsing Errors (ValueError on connect)

[jwp]

When connecting to servers that are not actually PostgreSQL, trap version parsing exceptions and issue a client warning instead.

Given the presence of a new server_version client parameter, use it instead of the version presented by the server averting the warning.

[dtpryce]

We have found this ValueError when connecting to older PostgreSQL instances also

[jwp]

It's only particular builds of PostgreSQL. Specifically, debian/ubuntu packages have chosen to modify the server_version issued to the client in a way that would (likely) break any driver/application that is splitting/parsing the string. This is inconsistent with the source releases made by postgresql.org and is not a modification that clients/applications can/would/should anticipate.

[dtpryce]

Yeah we are seeing this on an old postgres that has server version = 10.9 (Ubuntu 10.9-0ubuntu0.18.04.1)
If that helps you debug the issue.

I have a fix locally for that one module versionstring if you want it? Might not be too clever just an if statement to check the length of the expected version string.

[jwp]

I think they've released builds like this for some time. It is a known incompatibility.

The change that I will be committing regarding the issue will allow users to compensate by explicitly stating the server version. This is preferable as it allows for compensation of any variation, which is useful beyond one errant build.

[jpalladino84]

Hi, I was just wondering if there was any movement on this? I am using the Postgres docker container and it is setting my PG_VERSION to PostgreSQL 13.3 (Debian 13.3-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit which is resulting in the versionstring.py error: invalid literal for int() with base 10: '3 (Debian 13.

I like your thoughts around passing in the version instead of trying to derive it and was wondering if there was an ETA or if I should attempt to this in for the time being?

[jwp]

My desire to implement this has stalled as the effect of the incompatibility has been present for so long. Either the driver has been ed locally already or it's not being used to connect to instances of those builds. Also, I'm not optimistic that a server version override is actually superior to runtime ing the version string parser. The latter being a solution that is already available to users.

[4thel00z]

Can we have a sane default version in the cases where the version string cannot be parsed and a user warning ?
The way it is currently implemented it is simply unusable.

[awelzel]

Also, I'm not optimistic that a server version override is actually superior to runtime ing the version string parser. The latter being a solution that is already available to users.

Just ran into this using the postgres docker image from Docker hub: https://hub.docker.com/_/postgres

This is what I'm using as a runtime to work-around it:

import re

import postgresql
import postgresql.versionstring

# monkey  postgresql.versionstring.split to accept 14.5 (Debian 14.5-1.pgdg110+1)

_orig_split = postgresql.versionstring.split

def _monkey_split(vstr):
    m = re.match("^([0-9]+\.[0-9]+[^\s]*)\s+\(.+\)$", vstr)
    if m is not None:
        vstr = m.group(1)
    return _orig_split(vstr)

postgresql.versionstring.split = _monkey_split