Re: [Proposal] add portaddr like hostaddr

Hi Denis / Jacob!

Thank you both for the time you put into this, including reading the
pgcli code.

> I think Denis has this right. You're misinterpreting what host and
> hostaddr "mean", in a broader sense, and so the suggested split of
> port/portaddr is drawing a parallel where none exists.

Point taken. Spelling out what convinced me: when hostaddr is present,
host keeps real name-based duties, TLS server name and certificate
check, GSSAPI principal. The port coordinate has no counterpart for
any of those; the only consumer of a "logical port" would have been the
passfile lookup. That is too little to hang a host/hostaddr-style
split on, so I'm dropping portaddr and withdrawing the CommitFest
entry.

> Maybe there are good features that would help the UX for a local SSH
> tunnel, but I don't get the sense that this is one.

May I take you up on that? The residual case is a tunnel on a dynamic
local port: no passfile line can be written in advance, and a client
that wants to keep .pgpass working today has to reimplement the
passfile parser on its side. The first version of this proposal [1]
was a narrowly scoped, lookup-only knob (passfileport): it only changes
the port used in the passfile lookup, and claims nothing about
identity, PQport(), or the socket. Is that a shape worth refining, or
do you see this whole thing as belonging client-side, full stop?

Independently of that, I would like to send a small doc patch for the
pgpass section documenting the workaround that exists today (host +
hostaddr, fixed local port written into .pgpass); the same confusion
keeps resurfacing in client issue trackers.

[1] https://postgr.es/m/c0dfc226-9fbd-450b-a470-00f5427077a4@gmail.com

Thank you,
BR,
Diego