On Monday, 12 August, 2019 13:52, Simon Slavin <slav...@bigfraud.org> wrote:
>On 12 Aug 2019, at 8:20pm, Thomas Kurz <sqlite.2...@t-net.ruhr> wrote: >> c) To enable the new DATE interpreation, we do: >> CREATE TABLE TEST VERSION=3.34 --> will be stored the same way >And now you have a file which can't be edited with old versions of >the CLI. However you cut it, you have compatibility problems. These issues already exist in the current codebase. For example, older versions of SQLite3 have no clue what to do with things like indexes on expressions, conditional indexes, or even descending indexes. If such a database is attempted to be accessed by a version of SQLite3 that does not understand the features, the database is treated as being corrupt. However, since those features merely "overload" existing capabilities, removing them renders the database useable by those earlier versions. Similarly, I suppose one could "uverload" a standard float or integer type to handle datetime data and this would not affect the underlying database structure, but would merely be seen as "corruption" by a version of SQLite3 that does not know how to parse the new sugar. Removing the sugar would render the database once more accessible by the older versions. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
