Re: [Proposal] add portaddr like hostaddr

Hi,

I do not think portaddr should be added to libpq.

Context
-------

The main use case comes from pgcli:

* pgcli opens an SSH tunnel on a random local port;
* it replaces the original database port with that local port;
* the existing .pgpass entry no longer matches;
* portaddr is proposed so that libpq connects to the local port but
searches .pgpass using the original port.

Why this should not be in libpq
-------------------------------

1. This is a client-side problem.

The two ports exist only because pgcli created the tunnel. PostgreSQL
does not know about the local port. A normal libpq connection has one
host and one port.

2. hostaddr is not a good model for this.

host and hostaddr are a host name and its numeric network address.
This distinction is needed for DNS, GSSAPI, and TLS.

Ports do not have names and addresses. port and portaddr would be two
different ports with different purposes:

* port would identify an entry in .pgpass;
* portaddr would be the port used for the connection.

This gives a new and unclear meaning to port.

3. The change is much larger than the use case.

It adds a new libpq parameter, environment variable, public function,
and special handling in psql, pg_isready, pg_upgrade, and tests.

Also, the DBeaver example does not show a need in libpq because
DBeaver uses pgJDBC.

What should happen instead
--------------------------

The client that creates the tunnel should also manage the mapping between:

* the original database endpoint; and
* the local tunnel endpoint.

It should handle the password lookup itself, use a tunnel-specific
passfile, or manage its local ports in another way.

A pgcli implementation detail should not become a new public libpq
connection concept.

Best regards,
Denis Smirnov