Re: [HACKERS] libpq++

Vince Vielhaber <vev@michvhf.com> writes:
> Are there any glaring problems that require immediate attention that you
> know of?  I see it hasn't been touched since around '97.

The connection-related routines desperately require work; the only
interface is equivalent to PQsetdb(), which means there's no way to
specify username/password.  (Except by passing them via environment
variables, which is a kluge.)  The code should be calling PQsetdbLogin
and there need to be a couple more connection parameters for username/
password.

I'd also like to see a connection method that interfaces to
PQconnectdb() and passes everything in a string, forgetting the
pgEnv stuff entirely.  That's the only way that won't require
further attention if more connection parameters are added to libpq.

Also, if the routines immediately around the connection code are
any indication, the library is just crawling with bugs.  A few
examples:

1. PgConnection::Connect tests "if (errorMessage)" ... where
errorMessage is a locally declared char array.  In other words
the if() tests to see whether the address of errorMessage is non-null.
This means that PgConnection::Connect *always* thinks it has failed.
The symptom that has been complained of is that if PQsetdb actually
does fail, no useful error message is available, because
PgConnection::Connect has overwritten it with the usually-null
message from fe_setauthsvc().

2. If it were coded as probably intended, ie "if (errorMessage[0])",
then it would not be testing the *connection* status but only whether
fe_setauthsvc was happy or not.  The test should really be looking at
the returned pgConn.

3. If it's gonna call fe_setauthsvc, one would think it should not go
ahead trying to make the connection if fe_setauthsvc fails.  But it does.

4. It probably shouldn't be calling fe_setauthsvc in the first place,
that routine being obsolete and deprecated.

5. Why are the caller(s) of PgConnection::Connect not noticing its
failure return status?

I got sufficiently discouraged after deconstructing that one routine
that I didn't go looking for more problems.  Five bugs in ten lines
of code is not promising...
        regards, tom lane