"The first proposal seems to me a very good one and contributes to clarity in programs. The second one is of dubious value and a poor tradeoff in my opinion."
Hmm. Perhaps. I currently do this in my wrapper anyway and it's annoying, so it's not completely devoid of value. -----Original Message----- From: John Stanton [mailto:[EMAIL PROTECTED] Sent: 03 November 2005 15:25 To: sqlite-users@sqlite.org Subject: Re: [sqlite] Request for comment: Proposed SQLite API changes The first proposal seems to me a very good one and contributes to clarity in programs. The second one is of dubious value and a poor tradeoff in my opinion. JS [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]> >
