Fabien COELHO <coe...@cri.ensmp.fr> writes: > Small v7 update, sorry for the noise.
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. And it also fails to cover DescribeQuery, which arguably should set these variables as well -- 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.) 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. 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. regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers