Re: BUG #15025: PSQL CLI - inconsistency when both -d and -U supplies a username

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #15025: PSQL CLI - inconsistency when both -d and -U supplies a username
Дата
Msg-id 16151.1517173540@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #15025: PSQL CLI - inconsistency when both -d and -Usupplies a username  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: BUG #15025: PSQL CLI - inconsistency when both -d and -U supplies a username  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
Bruce Momjian <bruce@momjian.us> writes:
> Oh, I wasn't aware a failed login left us with a 'conn'.

Sure, it's what's carrying the error message.  But it's also got all
the actual connection parameters filled in.

After further experimentation it seems like the has_connection_string
logic in do_connect() causes the \c case to behave pretty much as you'd
want:

$ psql -U user1 -d "postgresql://user2@localhost/postgres" -W
Password: 

postgres=> \c -
Password for user user2: 
You are now connected to database "postgres" as user "user2".
postgres=> \c postgresql://user1@localhost/postgres
Password: 
You are now connected to database "postgres" as user "user1".


So I now think the comment I added to do_connect() is unduly pessimistic,
and it's fine to keep using "prompt_for_password(user)" for a forced
password prompt there.  There may still be use-cases where it gets it
wrong, but they're too narrow to be worth giving up the helpful prompt
altogether.

            regards, tom lane


В списке pgsql-bugs по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: BUG #15025: PSQL CLI - inconsistency when both -d and -Usupplies a username
Следующее
От: Andres Freund
Дата:
Сообщение: Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in aninfinite loop