On May 23 11:30, [EMAIL PROTECTED] wrote:
> I'm currently trying to understand how to deal with the return values
> of PGresultStatus in terms of error handling in my application. The
> postgres manual describes the return codes of PGresultStatus as:
>
> PGRES_EMPTY_QUERY: The string sent to the server was empty.
> PGRES_COMMAND_OK: Successful completion of a command returning no data.
> PGRES_TUPLES_OK: Successful completion of a command returning data.
> PGRES_COPY_OUT: Copy Out (from server) data transfer started.
> PGRES_COPY_IN: Copy In (to server) data transfer started.
> PGRES_BAD_RESPONSE: The server's response was not understood.
> PGRES_NONFATAL_ERROR: A nonfatal error (a notice or warning) occurred.
> PGRES_FATAL_ERROR: A fatal error occurred.
>
> My question is, what constitutes a PGRES_FATAL_ERROR or a
> PGRES_BAD_RESPONSE?
AFAIK, at the moment, libpq doesn't return a PGRES_BAD_RESPONSE status
for any operation. (Furthermore, I think there're some situations where
it should do, like in the not understood or incomplete messages in
pqParseInput?() family. I'm also wondering the thoughts of developers
if I'd propose I patch for this.)
To learn more about in which situations libpq turns PGRES_FATAL_ERROR
flag on, you can make a
grep PGRES_FATAL_ERROR -RHn src/interfaces/libpq
call in the PostgreSQL's source directory. (Or better use cscope.)
Regards.
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
