On May 17, 2018, at 12:54 PM, Simon Slavin <slav...@bigfraud.org> wrote: > > On 17 May 2018, at 7:13pm, Dominique Devienne <ddevie...@gmail.com> wrote: > >> I think I'm not alone in wishing there was a way to disable all legacy >> backward compatibility "warts". > > However, doing it properly might be how SQLite 4 would start -- by resetting > all "historical compatibility" problems. Not only for understanding SQL, but > _v2() calls, supporting old versions of the database format, and such stuff. > It can also be stricter about rejecting bad SQL syntax or corrupted database > files. And it doesn't have to compile on ancient versions of compilers.
That sort reasoning gave us Python 3, which forked the Python community for about a decade. I’m not sure how well that applies to SQLite, since the ecosystem around SQLite isn’t as complex as with Python. The fan-out is much shallower with SQLite than with Python, where Python program A depends on module B, C, and D, and module C depends on E, F, G, and H… In the SQLite world, it’s pretty much a fan-out level of 2 or 3 everywhere: program A uses SQLite3, possibly through intervening library B, end of story. I suppose the most relevant way SQLite’s ecosystem is like that of Python’s ecosystem is around DB compatibility. Any given program that consumes SQLite DBs now can open any DB created with an older version and often those created by newer versions of SQLite as well. That goes away if SQLite4 is allowed to be incompatible. Still, there are some things it would be nice to get rid of, as you say. Besides your list, some of the SQLite limits are now looking a little tight, like the 2 GiB BLOB size limit: https://sqlite.org/limits.html It might be nice to “pull a ZFS” on SQLite and redo it all to use 2^128 everywhere so the limits never matter again. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
