>>> I created a patch which enables it to use the existing connection in >>> such a case (unlike what we currently do). It modifies >>> connectDBComplete() and PQconnectPoll() to also include states >>> pertaining to password being accepted from the user. That is, the >>> state machine in PQconnectPoll() is further extended to include a >>> connection state called CONNECTION_ASKING_PASSWORD which is entered >>> when server sends AUTH_REQ_MD5 or AUTH_REQ_PASSWORD auth requests. >> >> Great! The new client state seems to be effective also for MD5. But >> it seems to break existing libpq client doing the same authentication >> sequence as current psql. Some means would be necessary to switch the >> behavior when password is not previously provided but needed by the >> server, or make the first half of the connection sequence to be >> compatible to the current sequence - in other words - It should be >> that when the user finds stauts is CONNECTION_BAD and >> PQconnectionNeedsPassword() == true, the user can throw away the >> connection and make new connection providing password, and also can >> send password on existing connection. > > The first half of connection sequence remains same except for one > change: in PQconnectPoll(), when in case CONNECTION_AWAITING_RESPONSE, > if server sends md5/password authentication request, it returns > PGRES_POLLING_WAITING_PASSWORD, which, back in connectDBComplete() > sets conn->password = true and conn->status = > CONNECTION_ASKING_PASSWORD. Back in main(), this causes a password > prompt and then the second half of the connection sequence. Hence > pg_fe_sendauth() is not called in this first half unless it's a > different authentication method than md5 and password.
One more thing that I forgot to mention is that connection sequence would enter CONNECTION_ASKING_PASSWORD in the first half, only if password is currently not set to a non-empty value that is ( conn->pgpass ==NULL || conn->pgpass[0] = '\0' ) is true. I was wondering what would be the case for other applications using libpq when they return from connectionDBComplete() with conn->status set to CONNECTION_ASKING_PASSWORD, provided they have not set conn->pgpass to a non-empty value.If they are currently handling this based on CONNECTION_BAD, then this change does no good to them. In fact there needs to be a way for them to get CONNECTION_BAD. Since, this whole patch is about not having to drop-and-reconnect *in case of password prompt*, how it changes libpq for other applications also needs to be addressed here. especially for md5/password authentication cases. Currently, any attempt to connect using empty or NULL password results in CONNECTION_BAD for all libpq based clients. Thoughts? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
