A good and new safe could be a sqlite3_close_v2() call prototyped like

int sqlite3_close_v2(sqlite3 * db, int closePendingStatements);

and current sqlite3_close() call could become

int sqlite3_close(sqlite3 * db)
        return sqlite3_close_v2(db, 0);

In this way, current running code does not need to be changed, and
developers that use v2 interface with close = 1 are aware of what
they are doing.

This not only mantains backward compatibility but also give more
control of sqlite behaviour.
-----Original Message-----
[mailto:[EMAIL PROTECTED] On Behalf Of D. Richard Hipp
Sent: terça-feira, 13 de maio de 2008 20:51
To: General Discussion of SQLite Database
Subject: [sqlite] Proposed SQLite C/C++ interface behavior change.

The currently documented behavior of sqlite3_close() is that  when it  
called on a database connection that has unfinalized prepared  
statements is to return SQLITE_BUSY and fail to close the connection.   
The rational is that we did not want a call to sqlite3_close() to  
destroy sqlite3_stmt* pointers out from under other subsystems.  But  
for version 3.6.0 we are considering a behavior change in which a call  
to sqlite3_close() will silently and automatically call  
sqlite3_finalize() on all outstanding prepared statements.

This is, technically, an incompatible change and we strive to avoid  
incompatible changes. But we think it unlikely that this change will  
cause any problems, and in fact we suspect it will likely fix more  
bugs than it will induce.  But before we move forward, it seems good  
to submit the idea to the community of SQLite users and programmers.

Does anybody have any thoughts on this proposed behavior changes for  
the sqlite3_close() interface?

D. Richard Hipp

sqlite-users mailing list

sqlite-users mailing list

Reply via email to