Connection problem

[emordnylap]

Connection problem

[jwp]

As long as 1) a link to the Docker image image is provided on postgresql.org

I suspect the debian packages provided by apt.postgresql.org work with the driver.

As to why they chose to make that image with something other than their own packages, I'm at a loss.

There is apparently some conflict that I'm not aware of?

As a workaround to the warning, a client parameter dictating the server version would be accepted providing an override

Do you feel such a patch is more graceful than the version parsing fix?

Yes. Also, it's actually useful.

I tested your driver on every Postgres server I have access to (versions from 10 to 13), and it does not work anywhere.

It works on every Postgres server I have tested it on.

a build from postgresql source

Should I suggest my admins to rebuild the prod DB? 🙂

I would suggest using a build that didn't modify that version string.

a runtime patch cited in #105, considering how trivial it is, you can just edit the file yourself without much difficulty.

Not nice... I need to put a comment in the code like "the driver fails here and we need to patch it"... It is supposed to work out of the box, isn't it?

A runtime patch is a pretty reasonable way to handle exceptional cases like this.

It's open source. Being able to fix it yourself really is an awesome feature.
Sometimes fixes are very technical and require knowledge of the project being corrected, but in this case it's simple.

[emordnylap]

Sorry, @jwp I should have conducted some research prior to submitting a ticket.

But after skimming through the recent tickets I feel a bit confused: #105, #101, #95, #93... Every third issue recently was about this problem. From all these conversations I am still not getting, why did you not include the fix right into the library? Thank you.

[jwp]

In my humble opinion it is exactly the issue that can and must be solved by patching the driver.

The driver works as intended... There is nothing to be done with regards to this specific issue.

The only compromise that I've considered committing is an exception trap that issues a warning of a malformed server version. As a workaround to the warning, a client parameter dictating the server version would be accepted providing an override for whatever is presented to the client during negotiation.

I should emphasize that this is only being considered because it seems reasonable that PostgreSQL forks or PQ servers may have adjusted the server version with reasonable purpose. However, I suspect that that is not actually common as they would likely prefer to not risk breaking applications.

I asked our devops people and found out that "this variant" is the

This driver is only tested against source releases made by postgresql.org.

If that docker image exhibits distinctions significant enough to break this driver and likely other applications that choose to switch on the version, it might as well qualify as a variant.

...

I'm having a very difficult time understanding why forcing me to commit a patch is important to you.

There are already many options available. A debian port of the driver, apt.postgresql.org packaging, a build from postgresql source, a runtime patch cited in #105, and, considering how trivial it is, you can just edit the file yourself without much difficulty.

[jwp]

Duplicate of #105

The runtime fix mentioned in 105 should fix the issue.

[jwp]

Not a problem. I don't mind adding keyword endpoints.

I think I've made it clear that my position is that the real issue is not actually solved by patching the driver.
Yes, the exception goes away, but the actual, root, problem remains.
Applications, using any driver, needing/choosing to switch on the version are likely broken by this variant of PostgreSQL as well.

[emordnylap]

the real issue is not actually solved by patching the driver.
the exception goes away, but the actual, root, problem remains.

Sorry, I am afraid I am not following, what do you call the "root cause"? From other tickets I got that you have some concerns about their decicion to slightly change the format of the version string. While it is really unfortunate that it breaks your driver, it happens quite often in the software world – components may need to adjust/adapt for each other.

In my humble opinion it is exactly the issue that can and must be solved by patching the driver.

by this variant of PostgreSQL

I asked our devops people and found out that "this variant" is the official Docker image for this version of Postgres (I fixed the actual error text "Ubuntu" --> "Debian", initially copypasted from another issue).

[emordnylap]

a malformed server version
This driver is only tested against source releases made by postgresql.org.

As long as 1) a link to the Docker image image is provided on postgresql.org web site, and 2) the image build script seems to be maintained by the same community as the rest of PostgreSQL, in my opinion, such Docker images can be considered same valid releases as the binaries available on postgresql.org web site.

As a workaround to the warning, a client parameter dictating the server version would be accepted providing an override

Do you feel such a patch is more graceful than the version parsing fix?

why forcing me to commit a patch is important to you

I am sorry if I pushed it too hard, but the reason might be my aspiration to make the world a bit better, which your driver is definitely capable to do 🙂 I tested your driver on every Postgres server I have access to (versions from 10 to 13), and it does not work anywhere. My fear is that every new user willing to try the driver, will encounter this bug, and assume that the driver is not maintained any more and just switch to something else. Not many people will dig in closed bug reports to find the solution (even if it's trivial).

debian port of the driver
apt.postgresql.org packaging

My image with the client service might be not Debian-based, and I use dependency managers such as Poetry, Pipenv, etc, where I would like to have a common way of working with dependencies.

a build from postgresql source

Should I suggest my admins to rebuild the prod DB? 🙂

a runtime patch cited in #105, considering how trivial it is, you can just edit the file yourself without much difficulty.

Not nice... I need to put a comment in the code like "the driver fails here and we need to patch it"... It is supposed to work out of the box, isn't it?