Andrew Chernow <[EMAIL PROTECTED]> writes: > Gregory Stark wrote: >> Surely you would just provide a function to get pqtypes errors separate from >> libpq errors?
> That's extremely akward. Consider the below. I'm just as suspicious of this as Greg is. In particular, I really disagree with PQgetf storing an error message into a PGresult, because that creates a semantic inconsistency. Up to now, PGresults have come in two flavors, "okay" (which might hold data) and "error" (which hold error messages). Now you're proposing to stick an error message into an "okay" data-holding PGresult. Does that turn it into an "error" result? Does its PQresultStatus change? Does it maybe forget the data it used to hold? An even more fundamental objection is that surely PQgetf's PGresult argument should be const. > 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)); This example is entirely unconvincing. There is no reason to be checking PQresultErrorMessage at this point --- if you haven't already checked the PGresult to be "okay", you should certainly not be trying to extract fields from it. So I don't see that you are saving any steps here. > PQgetf should behave exactely as PQgetvalue does, in regards to errors. Uh-huh. You'll notice that PQgetvalue treats the PGresult as const. > Same holds true for PGconn. I'm not convinced about that side either. It doesn't fail the basic const-ness test, perhaps, but it still looks mostly like you are trying to avoid the necessity to think hard about how you're going to report errors. You're going to have to confront the issue for operations that only take a PGresult, and once you've got a good solution on that side it might be better to use it for PQputf too. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers