From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Oleksandr Shulgin <oleksandr(dot)shulgin(at)zalando(dot)de>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, exclusion(at)gmail(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #16486: Prompted password is ignored when password specified in connection string |
Date: | 2020-09-02 14:46:19 |
Message-ID: | 317208.1599057979@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 Wed, Sep 2, 2020 at 09:54:37AM +0200, Oleksandr Shulgin wrote:
>> AFAIK, there is nothing in the protocol that forces psql to make an extra
>> connection attempt. If libpq provided a means to pass a password-prompt
>> callback, no extra connection would be needed I think?
> That is true. I don't think we want the backend to be kept open waiting
> for someone to type a password, which is why, I think, we don't do it
> that way.
Yeah, I think this is an ancient value judgement. Sure, it's pretty
questionable whether spawning a backend a second time is better than
tying one up waiting for a human to type a password. (It's going to
be spending a lot of time waiting for that human later on, anyway.)
The real point IMO is that libpq's connection API is already
unreasonably complicated, and providing a callback of this sort
would make it even messier. A different client library might make
a different choice, perhaps.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2020-09-02 15:39:17 | Re: BUG #16557: getProcedureColumns() function returns columns, when there is no existing Stored Procedure in the DB |
Previous Message | Bruce Momjian | 2020-09-02 13:18:58 | Re: BUG #16486: Prompted password is ignored when password specified in connection string |