Ilja Booij wrote:
Larry Rosenman wrote:
Since I play on the PostgreSQL team, what version of PostgreSQL didn't
give y'all the right info? (this seems like a bug to me, and did y'all
report it to the PostgreSQL team?)
[snip]
Postgresql 7.4.2 (Debian backport from www.backports.org)
I didn't report it to the PostgreSQL team. I probably should. I'll do it
right now, but first I'll check if this behaviour wasn't reported earlier.
After re-reading the docs, I get the feeling that we might've
interpreted the docs in the wrong way. It states this:
""
#
PQstatus Returns the status of the connection.
ConnStatusType PQstatus(const PGconn *conn)
The status can be one of a number of values. However, only two of these
are seen outside of an asynchronous connection procedure - CONNECTION_OK
or CONNECTION_BAD. A good connection to the database has the status
CONNECTION_OK. A failed connection attempt is signaled by status
CONNECTION_BAD. Ordinarily, an OK status will remain so until PQfinish,
but a communications failure might result in the status changing to
CONNECTION_BAD prematurely. In that case the application could try to
recover by calling PQreset.
See the entry for PQconnectStart and PQconnectPoll with regards to other
status codes that might be seen.
""
It basically says that a *communication failure* will lead to a status
of CONNECTION_BAD. So, stopping the Postgres server and requesting
PQstatus() will give the result from the previous communication, which
was before that shutdown of the server. After trying a query, which
obviously fails, PQstatus() does return CONNECTION_BAD.
To conclude: It's not a bug, it's just that the PQstatus() function does
less than we though it would do.
Ilja
