From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com>, David Fetter <david(at)fetter(dot)org>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Remove psql's -W option |
Date: | 2018-07-23 16:08:16 |
Message-ID: | 17744.1532362096@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I also think your other question is a good one. It seems like the
> fact that we need to reconnect -- rather than just prompting for the
> password and then sending it when we get it -- is an artifact of how
> libpq is designed rather than an intrinsic limitation of the protocol.
Well, it's a limitation of the libpq API. The problem is that it's the
application, not libpq, that's in charge of actually asking the user for
a password. Right now we inform the app that it needs to do that by
passing back a failed PGconn with appropriate state. We could imagine
passing back a PGconn with a half-finished open connection, and asking
the app to re-submit that PGconn along with a password so we could
continue the auth handshake. But it'd require changing apps to do that.
Also, doing things like that would incur the risk of exceeding
authentication_timeout while the user is typing his password. So we'd
also need some additional complexity to retry in that situation.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2018-07-23 16:11:13 | Re: [HACKERS] logical decoding of two-phase transactions |
Previous Message | Alvaro Herrera | 2018-07-23 16:03:32 | Re: cached plans and enable_partition_pruning |