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