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/[email protected] Thank you, BR, Diego
