From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Bizarre behavior in libpq's searching of ~/.pgpass |
Date: | 2018-07-31 21:20:10 |
Message-ID: | 10439.1533072010@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> 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"?
Here's an updated patch that fixes that aspect too. Although this
might seem independent, it's not really: this version of the patch
eliminates the corner case where we have neither a host or hostaddr
to search for. The check for empty hostname in passwordFromFile is
thereby dead code, though it seemed better style to leave it in.
(Basically, the point here is to guarantee that passwordFromFile has
the same idea of what host/port we are going to connect to as the
actual connection code does. That was not true before, either for
the host or the port :-()
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
search-pgpass-with-host-or-hostaddr-2.patch | text/x-diff | 15.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2018-07-31 21:20:27 | Re: Online enabling of checksums |
Previous Message | Daniel Gustafsson | 2018-07-31 21:11:02 | Re: Online enabling of checksums |