Gregory Stark wrote:
> "Andrew Chernow" <ac@esilo.com> writes:
>
>> Shoot! Feels like you always miss something.
>>
>> The patch uses PGconn's PQExpBuffer to set errors on a conn. Currently, there
>> is no access to this buffer other than PQerrorMessage. Is the below okay?
>
> Surely you would just provide a function to get pqtypes errors separate from
> libpq errors?
>
That's extremely akward. Consider the below.
int getvalues(PGresult *res, int *x, char **t)
{ return PQgetf(res, "get the int and text);
}
if(getvalues(res, &x, &t)) printf("%s\n", PQresultErrorMessage(res));
How would the caller of getvalues know whether the error was generated
by a libpqtypes API call or by a libpq API call (like PQgetvalue)?
PQgetf should behave exactely as PQgetvalue does, in regards to errors.
Same holds true for PGconn. Normally, you are using PQputf which sets
the error in PQparamErrorMessage. Then there is PQparamCreate(conn) or
PQparamExec(conn, param, ...) and friends? PQparamExec calls
PQexecParams internally which can return NULL, setting an error message
inside PGconn. We felt our light-weight wrappers should be consistent
in behavior. If you get a NULL PGresult for a return value,
PQerrorMessage should be checked.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
