🤖 New build scheduled with the buildbot fleet by @erlend-aasland for commit 5819902 🤖

If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again.

🤖 New build scheduled with the buildbot fleet by @erlend-aasland for commit 5165a3a 🤖

If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again.

🤖 New build scheduled with the buildbot fleet by @erlend-aasland for commit 1da6390 🤖

If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again.

FYI, the failing buildbot are also failing on main; they are unrelated to this PR.

Haven't checked this method for problems.
Please consider using sqlite3_total_changes64(), I'm afraid sqlite3_total_changes() will be easier to get wrong result.

total_changes doc:

The two functions are identical except for the type of the return value and that if the number of rows modified by the connection exceeds the maximum value supported by type "int", then the return value of sqlite3_total_changes() is undefined.

Haven't checked this method for problems.

Please do; I appreciate your review.

Please consider using sqlite3_total_changes64(), I'm afraid sqlite3_total_changes() will be easier to get wrong result.

Yes, I will make sure the 64-bit version is used, when available. Thanks for the heads-up!

FTR, I will revert the DML check change in this PR; that is cleaner.

Just found sqlite3_total_changes64() is a very new function, added in 3.37.0 (2021-11-27)

If change one row per second, it will overflow after 68 years:

>>> (2**31-1)/3600/24/365
68.09625973490614

Not afraid of you laughing, I hope a program can run 1000 years (or forever) without errors, in theory we can achieve this goal.

Just found sqlite3_total_changes64() is a very new function, added in 3.37.0 (2021-11-27)

Yes, both of the 64-bit changes APIs were added in 3.37.0.

Not afraid of you laughing, I hope a program can run 1000 years (or forever) without errors, in theory we can achieve this goal.

Absolutely. But I also like to keep in mind that perfect is the enemy of good. IMO, a some of the sqlite3 issues have fallen to this; the proposed solution is not perfect, so we're stuck with API pains and bugs. A pragmatic view may, in some cases, be beneficial.

For the record: for now, I think my alternative PR is the better solution for this issue.

Closing in favour of gh-93526