Skip to content

Return the libpq default port when blank in conninfo#492

Merged
larskanis merged 3 commits into
ged:masterfrom
cbandy:port-integer
Nov 17, 2022
Merged

Return the libpq default port when blank in conninfo#492
larskanis merged 3 commits into
ged:masterfrom
cbandy:port-integer

Conversation

@cbandy

@cbandy cbandy commented Nov 12, 2022

Copy link
Copy Markdown
Contributor

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.

	/*
	 * Next, work out the port number corresponding to each host name.
	 *
	 * Note: unlike the above for host names, this could leave the port fields
	 * as null or empty strings.  We will substitute DEF_PGPORT whenever we
	 * read such a port field.
	 */
		/* Figure out the port number we're going to use. */
		if (ch->port == NULL || ch->port[0] == '\0')
			thisport = DEF_PGPORT;

It has done this for a long time:

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 ged left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think it's worth adding tests for this?

@cbandy

cbandy commented Nov 15, 2022

Copy link
Copy Markdown
Contributor Author

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.

@larskanis

Copy link
Copy Markdown
Collaborator

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.

@larskanis

Copy link
Copy Markdown
Collaborator

Should we add DEF_PGPORT to PG::Constants?

@ged

ged commented Nov 15, 2022

Copy link
Copy Markdown
Owner

@larskanis Yeah, probably. Nice work on the test btw. Those helpers are awesome.

Comment thread spec/pg/connection_spec.rb Outdated
@larskanis larskanis merged commit 574ecad into ged:master Nov 17, 2022
@cbandy cbandy deleted the port-integer branch November 18, 2022 00:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants