Re: psql - add special variable to reflect the last query status
Fabien COELHO <coelho@cri.ensmp.fr>
From: Fabien COELHO <coelho@cri.ensmp.fr>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Pavel Stehule <pavel.stehule@gmail.com>,
PostgreSQL Developers <pgsql-hackers@postgresql.org>
Date: 2017-09-11T17:46:18Z
Lists: pgsql-hackers
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.
Commits
-
Add psql variables to track success/failure of SQL queries.
- 69835bc89888 11.0 landed