Re: [Proposal] add portaddr like hostaddr

Hi Diego,

> hostaddr is the first hop, the only thing libpq dials, and host is
> who the user says is at the end of it.

That is not the libpq model.

libpq describes an OS socket endpoint and, when required, a server name.
For TCP, hostaddr is the numeric destination address and port is the
destination port. When hostaddr is absent, host is resolved through DNS.
When both are present, host is retained for TLS and GSSAPI.

host is therefore a name used for address resolution and authentication,
not a general identity at the end of an arbitrary route. Its use as a
.pgpass lookup key does not change that model.

> The patch does not expose two endpoints: it exposes one endpoint and
> one identity.

By two endpoints I meant the two sides of the forwarding mapping created
by pgcli: the local listener and the remote database target.

The socket endpoint used by libpq is already complete:

127.0.0.1:39907

The remote target:

db.example.com:5432

belongs to the SSH forwarding configuration owned by pgcli. portaddr
would combine the address from the local endpoint with the port from the
remote endpoint. It does not complete one endpoint.

> What remains is the case where no port can be written in advance,
> because it does not exist yet.

The port exists before pgcli calls libpq. The current pgcli code starts
the SSH tunnel, reads local_bind_ports[0], and then passes that port to
PGExecute. libpq is never asked to connect without a known port.

pgcli creates the tunnel and owns both sides of the mapping. Once the
tunnel is started, pgcli knows the selected local port. It therefore has
all the information needed to construct consistent SSH forwarding and
libpq configuration: SSH maps the local endpoint to the remote database,
while libpq and .pgpass use that local endpoint.

How pgcli stores or generates this mapping is a pgcli implementation
detail. It does not require libpq to introduce a second port.

Best regards,
Denis Smirnov