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 19:38:46
Message-ID: 29202.1517168326@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:
> psql -d "postgresql://user2(at)momjian(dot)us/test" -U user1
> --> Password for user user1:
> but it wants the user2 password.

> It doesn't matter whether -U is first or last, it always prompts for the
> -U user, but connects as the -d user.

Bleah.

> Because the URI is parsed by libpq, I don't think we can do any better
> than just suppress the user name in the password prompt when a URI is
> used.

That doesn't seem very user-friendly at all. I think that the most
correct behavior in this case would be to throw an error because of the
conflicting command line parameters. Now admittedly, psql doesn't throw
an error for

psql -U alice -U bob

so maybe just silently making a choice is OK, but we need to be clear
as to which choice we made. Isn't it possible to get the URI parse
results back out of libpq?

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Bruce Momjian 2018-01-28 20:04:18 Re: BUG #15025: PSQL CLI - inconsistency when both -d and -U supplies a username
Previous Message Tom Lane 2018-01-28 19:32:53 Re: BUG #15033: Segmentation fault running a query