On May 23 11:30, jois.de.vivre@xxxxxxxxx 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.
