Hello Tom,
Hm. Looking closer at this, I see that it doesn't work so well after all to put the variable-setting code in ProcessResult: that fails to cover the ExecQueryUsingCursor code path.
Ok, I'll investigate this path.
And it also fails to cover DescribeQuery, which arguably should set these variables as well
And this one.
-- certainly so if it gets a failure. Maybe you could create a small subroutine along the lines of SetResultVariables(PGresult *result, bool success) for all three places to call. (ProcessResult certainly has already decided whether it's got a success, and I think the other paths would know that as well, so no need to re-extract it from the PGresult.)
Ok.
I think you're overly optimistic to believe that every failure will have a SQLSTATE; I don't think that's true for libpq-reported errors, such as connection loss.
Yep, I thought I was optimistic:-) Can I add a special SQLSTATE for that situation where libpq did not report an error?
Using upper-case TRUE/FALSE for the values of ERROR seems a bit ugly to me; we generally use lower case for other variable values, so I'd go with true/false.
Ok. The choice is not aesthetic but systematic: I use upper-case for all SQL keywords, and lower-case or capitalized for anything user land. I can put lower-case if you want.
-- Fabien. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
