Re: Bizarre behavior in libpq's searching of ~/.pgpass

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Jul 27, 2018 at 11:38 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I noticed that there's some strange coding in libpq's choice of
>> what hostname to use for searching ~/.pgpass for a password.

> Yeah, that's bad code. The intent was that if you set host=a,b you
> probably want to use either 'a' or 'b' as the thing to look up in
> .pgpass, not 'a,b', but the implementation leaves something to be
> desired.

Right. Closely related to that is that the existing code in
passwordFromFile behaves differently for null vs. empty hostname.
This is bad on its face, because nowhere else in libpq do we treat
empty-string parameters differently from unset ones, but it's particularly
a mess for the comma-separated-list case because then it's impossible
for one of the alternatives to be NULL. In the already-posted patch
I fixed that so that an empty alternative is replaced by DefaultHost
in passwordFromFile, and likewise for port (though I think the latter
case may be unreachable).

But now that I look at it, it seems like the code in connectOptions2
has also Gotten It Wrong. Shouldn't the replacement of "unspecified"
cases by DEFAULT_PGSOCKET_DIR/DefaultHost also happen on an entry-by-
entry basis, so that "host=foo," would behave as though the empty
entry were "localhost"?

regards, tom lane