To summarize my thoughts on this thread so far:
1. None of the stuff being discussed should cause a major version
change, such as to 4.x.y; a big leap like that should only be taken
for large and sweeping changes, such as incompatible file formats or
paradigm shifts.
Mainly, they should be given a lot of time to think through and
bundle a number of issues, such as 3.x.y did, and not just be done at
the drop of a hat like doing it now would be.
2. Any changes being discussed should just raise the version to
3.3.0; really, it is only changes to the third digit which shouldn't
break anything, while changing the second that could reasonably
happen.
3. Having sqlite3_step() return the actual error is indeed an
improvement, assuming that the error had always been detected at that
time, deferring its report is counterintuitive.
4. A rebinding change on SQLITE_SCHEMA errors should be done with a
new function name since it is significantly different behaviour and
effectively a wrapper over several other function calls. Let users
choose what they want to use.
5. That said, its fine to store the original SQL text in sqlite3_stmt
regardless of whether users use the new function or not, for
simplicity, and its storage may carry other uses later as well.
6. I suggest having a compile time pragma regarding SQL text storage
so that people wanting to save the most RAM can have it not stored
and lose the new function, while it is available by default otherwise.
-- Darren Duncan
