Dennis Cote wrote:
I think both of these proposed changes are useful enhancements to SQLite.
I also think it would be better to add a new sqlite3_step_v2() API
function that does this. This will eliminate the need to change the base
version number, since existing code can continue to use the existing
step function. New code, or those who want to modify their existing
code, could use the new function.
The new step function should be a wrapper around the existing step
function in much the same way as sqlite3_exec() wraps the entire
prepare, step, finalize process. It would do the enhanced error checks
and return the real error, or automatically re-prepare the SQL if the
error was SQLITE_SCHEMA.
This would give you the best of both worlds, backwards compatibility and
a cleaner API for new code.
I have to agree here; simply changing sqlite3_step() could cause
problems for code that links to sqlite as a shared library/dll and can't
be sure which minor version is installed. Currently it's usually
possible to simply drop in the latest version of the library to get the
latest features/optimizations/bug fixes; I think that behavior is
important to preserve.
The auto-compilation change is potentially a can of worms, because while
it's not likely in a sane environment, it's possible that a schema
change could render the original query uncompilable, particularly if
SQLite ever added support for dropping or renaming columns. Or the
authorizer callback could fail upon recompilation. The upshot is that
there are still going to be cases where a schema change could cause an
sqlite3_step() to fail so it would still be necessary to write defensive
code; the change would simply cause that code to be executed less
frequently.
