4 ms·
SQLite isn't that small, about 1.3M compiled as a shared library on my system, and the "amalgamation file" is 240k lines of code, or 8.2M (160k lines w/o commen
by Beltalowda 4y ago
SQLite isn't that small, about 1.3M compiled as a shared library on my system, and the "amalgamation file" is 240k lines of code, or 8.2M (160k lines w/o comments). I don't think a bunch of functions will add that much to it; it's probably more about developer time, maintenance burden, etc.
- lmkg 4y ago> it's probably more about developer time, maintenance burden, etc. I mean... SQLite is famous for having almost a thousand lines of test code per line of application code. So yeah, I think they view the functions not just in terms of implementing, but also in terms of a commitment to robust maintenance.
- sgbeal 4y ago> it's probably more about developer time, maintenance burden, etc. That's a large part of it, yes. The sqlite project has only 2 full-time core developers and, AFAIK, only 3 current part-timers who tend to work on more "outer rim" features like the shell app, the .Net bindings, and the new WASM/JS parts. Richard (sqlite architect/lead) has an explicit goal of supporting sqlite through at least 2050, and sqlite has a long history of strong backwards compatibility guarantees. Every feature (e.g. new SQL-facing function) added to it may well have to be maintained until 2050 by that small group of people. Thus Richard is necessarily extremely selective about what goes in.