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
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:
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