Jef Driesen <[EMAIL PROTECTED]> wrote: > > I think that approach should work. But the function sqlite3_commit_hook > is marked experimental in the documentation. What does that means? Is it > safe to rely on it? >
"Experimental" means that we reserve the right to change it in future releases of SQLite. Most of the API is guaranteed to continue to be supported in exactly its current form. So, for example, when we wanted to enhance the behavior of sqlite3_prepare() we had to do so by adding sqlite3_prepare_v2(), not by changing the existing sqlite3_prepare(). And when the reason for existance of the sqlite3_global_recover() API went away, we still have to have an API with that name that is a no-op. With sqlite3_commit_hook(), we don't want to be bound by that contract. If in the future somebody comes up with a great idea for enhancing the behavior of sqlite3_commit_hook(), we want to be able to make the change without adding sqlite3_commit_hook_v2(). Or if somebody finds a fatal flaw in the whole sqlite3_commit_hook() concept, we'd like to be able to remove the API all together. Sqlite3_commit_hook() will not change without good reason. But if a good reason does come up, because it is experimental, it might change. Does that mean you can't rely on it? I suppose the answer to that question depends on what you mean by "rely on". Most libraries treat *every* API as if it were experimental. This is especially true the open-source world. SQLite tries to provide some guarantee of compatibility from one release to the next in order to preserve backwards compatibility. But we also try to give ourselves some wiggle room by explicitly declaring certain functions as experimental and therefore subject to change. -- D. Richard Hipp <[EMAIL PROTECTED]> ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
