wallet: enable SQLite extended result codes #23112

With this change, we get more fine-grained error messages if something goes wrong in the course of communicating with the SQLite database. To pick some random examples, the error codes SQLITE_IOERR_NOMEM, SQLITE_IOERR_CORRUPTFS or SQLITE_IOERR_FSYNC are way more specific than just a plain SQLITE_IOERR, and the corresponding error messages generated by sqlite3_errstr() will hence give a better hint to the user (or also to the developers, if an error report is sent) what the cause for a failure is.

See the SQLite documentation https://www.sqlite.org/c3ref/extended_result_codes.html https://www.sqlite.org/c3ref/c_abort_rollback.html

In its default configuration, SQLite API routines return one of 30 integer result codes. However, experience has shown that many of these result codes are too coarse-grained. They do not provide as much information about problems as programmers might like. In an effort to address this, newer versions of SQLite (version 3.3.8 2006-10-09 and later) include support for additional result codes that provide more detailed information about errors.

Concept ACK. More precise information in the logs for troubleshooting in case of errors is better.

Something to review for is if we match on specific result codes anywhere in the code and if so, whether they need to be changed.

ack https://github.com/bitcoin/bitcoin/pull/23112/commits/90be29c5b52e68b5de8a3282cd83172fbf9acf1b

utACK 90be29c

A search for = SQLITE_ reveals that so far we don't check for specific error codes. Instead we usually check if the result is (un)equal to SQLITE_OK, SQLITE_ROW, SQLITE_DONE. We also use sqlite3_errstr in most places when the result code is not what we expected.

Our minimum Sqlite version is 3.7.17 and this is enforced in configure.ac, so that's good.

cc @achow101

ACK 90be29c5b52e68b5de8a3282cd83172fbf9acf1b

Code review ACK 90be29c5b52e68b5de8a3282cd83172fbf9acf1b

A search for = SQLITE_ reveals that so far we don't check for specific error codes. Instead we usually check if the result is (un)equal to SQLITE_OK, SQLITE_ROW, SQLITE_DONE.

Have also checked this, and checked the documentation referenced in the OP that these specific result codes are "primary result codes" that have no extended variants*

* there are

#define SQLITE_OK_LOAD_PERMANENTLY     (SQLITE_OK | (1<<8))
#define SQLITE_OK_SYMLINK              (SQLITE_OK | (2<<8))

but these are used internally in plugin/vfs handling and, as I understand it, not something ever returned on the outside API