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
Robert Haas writes:
> On Fri, Jul 27, 2018 at 11:38 PM, Tom Lane 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
On Fri, Jul 27, 2018 at 11:38 PM, Tom Lane wrote:
> I noticed that there's some strange coding in libpq's choice of
> what hostname to use for searching ~/.pgpass for a password.
> Historically (pre-v10), it just used the pghost parameter:
>
> conn->pgpass = PasswordFromFile(conn->pghost,
On 07/29/2018 11:15 PM, Tom Lane wrote:
> Here's a proposed patch to adopt that behavior. I'm still of mixed
> mind whether to push this into v10 ... but we definitely need some
> change in v10, because it's not acting as per its docs.
Is there actually a useful use case working in v10 and broken
I wrote
> I noticed that there's some strange coding in libpq's choice of
> what hostname to use for searching ~/.pgpass for a password.
> ...
> So my first thought was that we should go back to the pre-v10 behavior
> of considering only the host parameter, which it looks like would only
> require
I noticed that there's some strange coding in libpq's choice of
what hostname to use for searching ~/.pgpass for a password.
Historically (pre-v10), it just used the pghost parameter:
conn->pgpass = PasswordFromFile(conn->pghost, conn->pgport,
conn->
