API changes for SQLite are fine with me as long as the PHP folks keep up
with SQLite in terms of implementing SQLite hooks.
I'm not real experienced with SQLite, but I'm starting to learn a lot. I
use it with PHP 5.1 and PDOs. I find myself compiling the latest SQLite
CVS and the latest snapshot of PHP 5.1 about once a week. Can't live
without 'em.
Bob Cochran
Greenbelt, Maryland, USA
[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]>
