* Richard Hipp: > (1) You should be able to drop in SQLite 3.15.0 (or any other release > after 3.8.2) in place of SQLite 3.8.2 and everything will continue > working just fine. The only changes will be that the applications > will run a little faster. We carefully test backwards compatibility.
I did this once, admittedly on CentOS, but there SQLite is used in more places by the operating system itself. I did not encounter any problems. I didn't lobby Red Hat to upgrade the system library version because it was just a temporary situation for me. I don't know how open Canonical would be to upgrading SQLite in an LTS release, based on customer demand. Maybe it's worth a try? > (1a) Sometimes an application will do a SELECT without an ORDER BY > when the application really does need the data in a specific order. > This error is not noticed because SQLite happens to return the rows in > the desired order, just by chance. Upgrading to a newer version of > SQLite might change the output order. This is about the only > compatibility issues you can expect when upgrading SQLite. Notice > that this is a bug in the application, not a bug in SQLite. Query planner changes can also have negative performance impact. > (2) SQLite works fine with static linking. It can break POSIX locking if one process accesses the same database with two different SQLite code copies. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
