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 20:30:54 |
Message-ID: | 14400.1517171454@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:
> On Sun, Jan 28, 2018 at 02:38:46PM -0500, Tom Lane wrote:
>> Isn't it possible to get the URI parse
>> results back out of libpq?
> Well, there is PQuser(), but you need to pass a connection struct to
> that, and before you connect you don't have one.
Yeah, but we normally don't prompt for password till after a failed
connection attempt, at which point we can get the info. So I propose
something like the attached.
There's room for debate about what we ought to do when -W (--password) is
specified, but I think that that's not really that exciting because the
only real use-cases for it are noninteractive applications that aren't
going to care what the prompt is. So in the startup.c case I have it
just offering the neutral "Password: " prompt always. In the \c case,
I left it using the same initial username as it was before, because the
odds that that's right seem considerably higher with \c. You can still
fool it by giving a URI dbname to \c, so maybe there's an argument for
lobotomizing the initial prompt in \c too, but I didn't do that here.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
fix-username-in-password-prompts-1.patch | text/x-diff | 3.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2018-01-28 20:36:33 | Re: BUG #15025: PSQL CLI - inconsistency when both -d and -U supplies a username |
Previous Message | Bruce Momjian | 2018-01-28 20:04:18 | Re: BUG #15025: PSQL CLI - inconsistency when both -d and -U supplies a username |