On Thu, 3 Nov 2005 [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?
Not very valuable, IMHO. The current API has a known behaviour, and code
either side of the API change is not strictly compatible with the other
side.
>
>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?
Elsewhere, it was indicated that the authorizer callback would be called
upon recompile. Why would this be a problem? If the statement is
recompiled anyway, you'll already get the callback as well.
Perhaps a new API function to validate a sqlite3_stmt against the current
schema, and recompile if necessary, if recompile should only be done under
user code control.
>
>-- D. Richard Hipp <[EMAIL PROTECTED]>
>
>
--
/"\
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST MS ATTACHMENTS
/ \
