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
|
Список | 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 по дате отправления: