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

On Sun, Jan 28, 2018 at 03:30:54PM -0500, Tom Lane wrote:
> 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.

Oh, I wasn't aware a failed login left us with a 'conn'.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +