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-----
From: [EMAIL PROTECTED]
[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
[EMAIL PROTECTED]
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
