Re: Shouldn't .pgpass work with anything which uses libpq? - Mailing list pgsql-interfaces

From ljb
Subject Re: Shouldn't .pgpass work with anything which uses libpq?
Date
Msg-id avijra$2f0t$1@news.hub.org
Whole thread Raw
In response to Re: Shouldn't .pgpass work with anything which uses libpq?  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Shouldn't .pgpass work with anything which uses libpq?
List pgsql-interfaces
pgman@candle.pha.pa.us wrote:
>...
> OK, here is a patch I applied to 7.3.X and CVS head to fix the problem.
> 
> The basic issue is that PQsetdbLogin does the pgpass test and then calls
> PQconnectDB.  The fix is to do the pgpass test in PQconnectDB so both
> PQsetdbLogin and PQconnectDB can use it.

(Sorry about that. I posted a patch to one of the lists but it may not
have made it through. It looks like your patch is the same.)

> However, your posting brings up an interesting issue.  Our current code
> makes no distinction between "" as a password, and a NULL password. 
> They are both equivalent to "I have supplied no password".  If you
> create a public user with an empty password, "", there is no way to log
> in as that user, because "" is considered to be "no password".
> 
> I don't want to play with this in 7.3.X, but is it something we should
> consider cleaning up for 7.4?

There is a precedence for the current behavior. Another DBMS I've used
takes an empty password for an account to mean "this account is disabled".
Therefore it is impossible in that DBMS to have a valid account with no
password. Which to me is equivalent to PostgreSQL saying "if passwords are
enabled, it is impossible to login to an account with an empty or NULL
password". I like that behavior.


pgsql-interfaces by date:

Previous
From: Hiroshi Inoue
Date:
Subject: Re: ODBC fix
Next
From: ljb
Date:
Subject: Re: still memory leaks with libpgtcl