Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fkVgi-0002Tv-7K for pgsql-hackers@arkaria.postgresql.org; Tue, 31 Jul 2018 14:31:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fkVgg-00049M-A4 for pgsql-hackers@arkaria.postgresql.org; Tue, 31 Jul 2018 14:31:46 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fkVgf-00048X-Vc for pgsql-hackers@lists.postgresql.org; Tue, 31 Jul 2018 14:31:46 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fkVgd-0000CO-Cb for pgsql-hackers@lists.postgresql.org; Tue, 31 Jul 2018 14:31:44 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id w6VEVfpA011456; Tue, 31 Jul 2018 10:31:41 -0400 From: Tom Lane To: Robert Haas cc: PostgreSQL Hackers Subject: Re: Bizarre behavior in libpq's searching of ~/.pgpass In-reply-to: References: <30805.1532749137@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Tue, 31 Jul 2018 07:41:58 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11454.1533047501.1@sss.pgh.pa.us> Date: Tue, 31 Jul 2018 10:31:41 -0400 Message-ID: <11455.1533047501@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk 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 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