> This would break backward compatibility. It is necessary to be sure that > database files made with current versions of SQLite can be opened with old > versions back to 2013.
This is what I would call "forward compatibility": You expect an old application to be able to read file formats of a future version. Do you have an example where there is really required? Apart from database browsers I cannot think of many situations where an application has to read an arbitrary database created by an arbitrary application. It wouldn't know how to interpret data anyhow? > > Alternatively, one could introduce a pragma statement, say PRAGMA > > emulation=ver, that could default to 3.30 (or whatever) now and which > > doesn't change at all > This would break backward compatibility. It is necessary to be sure that > database files made with current versions of SQLite can be opened with old > versions back to 2013. I don't think it would break compatibility. If there's no space to include version information in the database file directly, it could e.g. be added to the table definition: CREATE TABLE whatsoever VERSION=3.30, just like the ENGINE keyword of MariabDB. Reading tables without a VERSION keyword are automatically interpreted in the version where this feature was introduced first. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
