Re: BUG #15025: PSQL CLI - inconsistency when both -d and -Usupplies a username
От | Bruce Momjian |
---|---|
Тема | Re: BUG #15025: PSQL CLI - inconsistency when both -d and -Usupplies a username |
Дата | |
Msg-id | 20180128200418.GA4380@momjian.us обсуждение исходный текст |
Ответ на | Re: BUG #15025: PSQL CLI - inconsistency when both -d and -U supplies a username (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #15025: PSQL CLI - inconsistency when both -d and -U supplies a username
|
Список | pgsql-bugs |
On Sun, Jan 28, 2018 at 02:38:46PM -0500, Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > psql -d "postgresql://user2@momjian.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? Well, there is PQuser(), but you need to pass a connection struct to that, and before you connect you don't have one. libpq's conninfo_uri_parse_options() is a static function so that can't be used. I don't see any libpq documentation saying that URIs override command-line specifications. -- Bruce Momjian <bruce@momjian.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 +
В списке pgsql-bugs по дате отправления: