I vote for the cleaner API changes even though they are
not 100% backwards compatible. Alternatively you could
have a brand new step function, leaving the old versions with
the same functionality.
With the recent numeric/integer/division change, the working
check clause and this proposed API changed shouldn't the version
number should be bumped to 4.0.0 to indicate incompatibility with
past versions?
--- [EMAIL PROTECTED] wrote:
> As currently implemented, when an error occurs during
> sqlite3_step(), the function returns SQLITE_ERROR. Then
> you have to call either sqlite3_reset() or sqlite3_finalize()
> to find the actual error code. Suppose this where to
> change in version 3.3.0 so that the actual error code
> was returned by sqlite3_step(). That would mean that
> moving from version 3.2.7 to 3.3.0 might involve some
> minor code changes. The API would not be 100% backwards
> compatible. But the API would be cleaner.
>
> What does the community think about such a change?
>
> Another proposal: Suppose that when creating an
> sqlite3_stmt using sqlite3_prepare, the original SQL
> text was stored in the sqlite3_stmt. Then when a
> schema change occurred, the statement was automatically
> recompiled and rebound. There would no more SQLITE_SCHEMA
> errors. But sqlite3_stmts would use a little more
> memory. And sqlite3_step might take a little longer
> to initialize sometimes if it found it needed to rerun
> the parser.
>
> What about this change? Is it a worth-while tradeoff?
>
> --
> D. Richard Hipp <[EMAIL PROTECTED]>
>
>
__________________________________
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com
