On 20 Oct 2019, at 8:53am, Thomas Kurz <sqlite.2...@t-net.ruhr> wrote:
> I'd kindly ask whether there is some sort of roadmap for SQLite development? Only private to the developers, probably just mentioning whatever they're worried about at the moment. Nothing public. > Someone recently pointed out how much he loves the "lite" and well-thought > features. I cannot see that: I observe that many "playground" gadgets keep > being implemented (like virtual columns, virtual tables, FTS3/4/5, ...), > where one might wonder about their relationship to "Liteness", whereas other > features, essential basics of the SQL standards, are still missing and there > is no indication they are to be added. It's worth remembering that almost all of the literally billions of installations of SQLite are in mobile phones or embedded controllers inside single-purpose machinery (e.g. your TV recorder, a crane balancing management system, a car-park ticketing system). These devices don't need complete implementations of SQL, they need fast response, low memory use, and low power use. That's why SQLite stays 'Lite'. You are never going to see a full implementation of SQL in SQLite. Here's why: the SQL standard is set out in ISO/IEC 9075-1:2016. It has 9 parts, and over half a megabyte of text. It's copyrighted, huge, difficult to understand, and almost nobody cares about more than three chapters of it. One copy costs around €162. Which would arguably be wasted since it gets reviewed and changed every two or three years, including right now. But you – yes, you ! – can get your features included in SQLite. Just join the SQLite consortium for US$85K/year. <https://www.sqlite.org/consortium.html> Those are the people who pay for SQLite. They get personal support and their own requirements catered for, up to and including new features, instant bug fixes, code examples and customised test suites for their chosen compilation options. The recent addition of support for the "WITH" construction was added because a consortium member requested a way to implement something, and that's how SQL does it. Alternatively make a suggestion that (a) lots of people want (b) will be simple to explain in the documentation (c) doesn't require significant work (d) doesn't make the source code or object code much bigger (e) won't break backward compatibility (f) doesn't add significantly to the test suite (g) doesn't violate the SQL way of doing things (h) the developers like (I think that's everything I've seen discussed here.) For example, BOOLEAN affinity has been frequently suggested, but the developers said adding tests for BOOLEAN type values to the test suite would be a lot of work, and make it take far longer to run because everything that handles values would have to be tested with BOOLEAN values. Another common request is full support for Unicode (searching, sorting, length()). But even just the tables required to identify character boundaries are huge. You are, of course, free to fork SQLite and add in all the features you want. Hope this helps. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
