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:


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

Reply via email to