Tuesday, October 29, 2019, 7:37:40 AM, Thomas Kurz <sqlite.2...@t-net.ruhr> wrote:
>> If an earlier version of SQLite attempts to read a database file >> that contains a generated column in its schema, then that earlier >> version will perceive the generated column syntax as an error and >> will report that the database schema is corrupt. > ...which leads me to some confusion. So there actually *are* > features breaking compability? Wouldn't that be a chance for full > date/time support as well? There are different types of compatibility (that probably have proper names). The main one that the SQLite devs (seem to) want to avoid is the case where someone has an existing app/program that uses SQLite. They upgrade their copy of SQLite to the latest, and that program suddenly stops working because of a change in SQLite. This type of "breaking compatibility" is very rare (the change in behaviour of ALTER TABLE RENAME, which now fixes references to a renamed table, is one of the few that comes to mind). The situaton described above is different: to get that situation, a database has to have been deliberately created/modified in a LATER version of SQLite and then handed over to a program using an earlier of SQLite to process. Note: simply _creating_ the database with a later version is [almost always] safe (so long as you only use features the older version understands): the problem comes if you deliberately make use of a feature (e.g. "generated columns") that only the later version supports. This is sort-of the equivalent of asking Microsoft Word 2.0 to open a file created with Word 2007. Graham _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
