Robert Haas <robertmhaas@gmail.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