Thread: meaning of PQresultStatus types
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? I took PGRES_BAD_RESPONSE to mean that the libpq library was older than the database being connected to and so the response was not being handled properly. I took PGRES_FATAL_ERROR to mean that critical system errors had occurred (like running out of memory). While googling for more information regarding this, I found people had said that this can be generated for any queries that were executed after a failed query. These posting were however very old and I didn't know if any of this had been changed. Could someone tell me where I can get more information regarding these two particular error codes or confirm/deny my assumptions? Thanks
jois.de.vi...@gmail.com 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? > > I took PGRES_BAD_RESPONSE to mean that the libpq library was older than > the database being connected to and so the response was not being > handled properly. > > I took PGRES_FATAL_ERROR to mean that critical system errors had > occurred (like running out of memory). While googling for more > information regarding this, I found people had said that this can be > generated for any queries that were executed after a failed query. > These posting were however very old and I didn't know if any of this > had been changed. > > Could someone tell me where I can get more information regarding these > two particular error codes or confirm/deny my assumptions? > > Thanks I forgot to mention that I am using Postgres 8.0.3
On May 23 11:30, jois.de.vivre@gmail.com 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.
jois.de.vivre@gmail.com writes:
> My question is, what constitutes a PGRES_FATAL_ERROR or a
> PGRES_BAD_RESPONSE?
FATAL is probably a bad choice of words here; it basically means any
error condition reported by the server that caused execution of your
query to be abandoned. NONFATAL_ERROR actually means "notice or
warning message", and isn't a possible return code from PQexec anyway.
I think BAD_RESPONSE is historical at the moment; I don't see it being
generated anywhere in the library.
regards, tom lane
Thanks for your reply, > FATAL is probably a bad choice of words here; it basically means any > error condition reported by the server that caused execution of your > query to be abandoned. NONFATAL_ERROR actually means "notice or > warning message", and isn't a possible return code from PQexec anyway. Just for anyone else wondering about this in the future, I found that PGRES_FATAL_ERROR can be a simple situation such as your query having a syntax error, or as serious as an outright database shutdown (i.e. connection lost).