Return the libpq default port when blank in conninfo#492
Conversation
PQport may return null or empty string when the same is set in connection options. Internally, libpq falls back to its configured default any time it reads these.
ged
left a comment
There was a problem hiding this comment.
Do you think it's worth adding tests for this?
|
I tried, though only briefly. The suite is set up to start a local Postgres on a high port, but this code path requires a working connection on the default port. |
|
My first thought was to follow libpq closely and return nil in this special case. But on the other hand it doesn't make much sense to handle this case specially at all. So I wonder why libpq doesn't return a valid port number in any case. It just increases complexity to handle null and empty port on the user side. So IMHO this PR is OK how it is. I added a test checking the both port return variations. |
|
Should we add |
|
@larskanis Yeah, probably. Nice work on the test btw. Those helpers are awesome. |
This is one potential fix for #491.
Internally, libpq checks for null or empty string stored in pg_conn_host and falls back to the configured default
--with-pgport. This does the same for our wrapper around PQport.It has done this for a long time: