On Thursday, 9 March, 2017 07:30, Dominique Devienne <ddevie...@gmail.com> wrote: > On Thu, Mar 9, 2017 at 3:05 PM, Keith Christian <keith1christ...@gmail.com> > wrote: > > At some point it's time to use a different database engine or offload > > to other code. Sqlite could easily burgeon to the size of the other > > databases if everything asked for was included. Where, then, would we > > get a small but still functional SQL engine?
> Ah, here we go again :) I knew this was coming. > First, you can always #ifdef. Have you opened the amalgamation recently, > and seen the large parts which can be enabled or disabled? > Second, those basic math functions are no more (or less) important than > the ones shipping with SQLite right now. By your argument, SQLite should ship > with none. > Third, you must have missed the evolution of SQLite these past few years > which added large parts (FTS3|4|5, FKs, CTEs, RBU, Session, JSON1, Row > Values, etc...) which are considerably larger than a few math functions. > Last but not least, it's trivial to not use what's there and available and > easily disabled at compiled time, or ignored at runtime. > While using what's not there, and not readily available w/o developer > skills, is considerably harder. --DD Well, I compile my own SQLite3 Amalgamation which includes the following extensions: from the SQLite site: amatch.c carray.c closure.c compress.c csv.c eval.c fileio.c fuzzer.c ieee754.c nextchar.c percentile.c regexp.c rot13.c series.c showauth.c spellfix.c totype.c vfsstat.c vtshim.c wholenumber.c but not: sha1.c shathree.c (and perhaps a couple more) note that fileio.c and shathree.c are inlined into shell.c, so in order to remove them I have to modify shell.c to ifdef them out when I am building. Extensions to the SQLite engine should be in the SQLite3.c code, not the shell.c code. In my opinion (and worth exactly what you are paying for it) extension functions should not be incorporated into shell.c at all, but the shell should be able to detect if they are present and adjust its behaviour accordingly, if that is desired, such as the new sha3sum dot-command. This also avoids the issue where there is something available in the shell (such as the sha3 and fileio functions) that are not available in the corresponding DLL. and some third-party extensions: unifuzz.c interpolate.c sqlite_mprint.c plus my own extensions: ipaddress.c IPv4/v6 PtoN/NtoP/Collation/SubnetMembership sqlautobusy.c Automatically ensures busy_timeout sqlfcmp.c Proper Floating Point comparisons and Half-Even rounding sqlfunc.c A bunch of running statistical functions including proper average sqlfwin.c A bunch of useful Windows API functions (GetUser/SID/translation/token membership, etc) sqlmath.c The entire standard gnu math library sqlhash.c md2/md4/md5/sha1hard/sha2/sha3 in pure C The compiled size is: 32-bit versions 2017-03-08 22:01 1,623,936 SQLite3.dll 2017-03-08 22:01 94,080 SQLite3d.exe 2017-03-08 22:01 1,668,992 SQLite3s.exe and the 64-bit version 2017-03-08 21:57 1,674,624 SQLite3.dll 2017-03-08 21:57 100,224 SQLite3d.exe 2017-03-08 21:57 1,742,720 SQLite3s.exe which is double the size, at least, of the base SQLite3.dll (I include all the same RTREE, FTS, JSON, etc). So adding extensions does increase the size significantly. However, this is not going to be running on memory constrained devices either. The APSW modules are each about 200K bigger than the base SQLite3.dll _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
