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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: akos(at)elegran(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #15025: PSQL CLI - inconsistency when both -d and -U supplies a username
Date: 2018-01-28 21:05:40
Message-ID: 16151.1517173540@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Bruce Momjian <bruce(at)momjian(dot)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(at)localhost/postgres" -W
Password:

postgres=> \c -
Password for user user2:
You are now connected to database "postgres" as user "user2".
postgres=> \c postgresql://user1(at)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andres Freund 2018-01-29 01:02:13 Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in an infinite loop
Previous Message Bruce Momjian 2018-01-28 20:36:33 Re: BUG #15025: PSQL CLI - inconsistency when both -d and -U supplies a username