Andrew Chernow <ac@esilo.com> 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
