Tom Lane wrote:
> 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.
Correct, I agree. Our thinking was flawed. The issue we face is that,
unlike getvalue, getf can fail in many ways ... like bad format string
or type mismatch. If you would rather us introduce a pqtypes specific
error for getf. putf doesn't suffer from this issue because it uses
PGparamErrorMessage.
>> 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
The issue is not a matter of know-how, it is a matter of creating
ambiguos situations in regards to where the error is (I'm thinking from
a libpq user's perspective). This only applies to PQparamExec and
fiends, NOT PQputf. All existing exec/send functions put an error in
the conn (if the result is NULL check the conn).
paramexec can fail prior to internally calling PQexecParams, in which
case it returns NULL because no result has been constructed yet. The
question is, where does the error go?
res = paramexec(conn, param, ...
if(!res)
// check pgconn or pgparam?
// can conn have an old error (false-pos)
Not using the conn's error msg means that one must check the param and
conn if the return value is NULL. I think the best behavior here is to
check PQerrorMessage when any exec function returns a NULL result,
including pqtypes. If not, I think it could get confusing to the API user.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
