Re: Shouldn't .pgpass work with anything which uses libpq?

Поиск
Список
Период
Сортировка
От ljb
Тема Re: Shouldn't .pgpass work with anything which uses libpq?
Дата
Msg-id avijra$2f0t$1@news.hub.org
обсуждение исходный текст
Ответ на Re: Shouldn't .pgpass work with anything which uses libpq?  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: Shouldn't .pgpass work with anything which uses libpq?
Список 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 по дате отправления:

Предыдущее
От: Hiroshi Inoue
Дата:
Сообщение: Re: ODBC fix
Следующее
От: ljb
Дата:
Сообщение: Re: still memory leaks with libpgtcl