tree bd8b3aed0a74eb29cb15f64bbf1d97ecc002a4f7
parent 985094601315c45c2e0a2ac8292df4c2f646c698
author Neels Hofmeyr <neels@hofmeyr.de> 1507254630 +0200
committer Neels Hofmeyr <neels@hofmeyr.de> 1507753939 +0200

less noise: simplify db_remove_reset()

db_remove_reset() needs to be called after each stmt run, whether it succeeded
or not.

In case sqlite3_clear_bindings() would fail to unbind a stmt, we would anyway
be beyond recovery. There seem to be no plausible situations where such failure
would occur, unless there have been no bindings in the first place.

In case there was an SQL stmt failure, sqlite3_reset() will re-barf the same
error message, we will always have logged it earlier already in the proper
context.

We are never evaluating the return value, nor would we know how to recover from
non-success.

The conclusions:
- db_remove_reset() does not need to log any errors.
- db_remove_reset() does not need to return success.

Change-Id: I21678463e59f607f5f5c5732963e274392f0fffd