We all know this but it bears repeating: 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?
On Thu, Mar 9, 2017 at 6:49 AM, Eric Grange <egra...@glscene.org> wrote: > A bonus of having them defined in the core is that it avoids the minor > inconsistencies that are bound to arise in custom implementations (starting > with the name of math functions) > > Main downside is probably not going to be the size, but that it reserves > more names, and may conflict with existing custom implementations. > > Eric > > On Thu, Mar 9, 2017 at 1:16 PM, R Smith <rsm...@rsweb.co.za> wrote: > >> I second this - Been having a hard time making basic queries with a simple >> x^y function in SQL for SQLite since there is no guarantee what the >> end-user's system will have it compiled-in. I can version-check or >> version-enforce easily, but compile-option check or enforce is a no-go. >> >> If we can shift the basic "Auto-included" feature set a few notches up, we >> can still have hardcore minimalist users compile their own (as they >> probably already do), but it would be nice to know a query running on a >> standard linux or Apple OS on the included SQLite will support some wider >> functions as a rule[1] without having to keep track. I realize this will >> take a time to permeate through the world, but it would be great to start >> asap. >> >> [1] Yes, there are threads on this same forum where I myself kicked >> against bloating SQLite with unneeded functionality as a rule, but perhaps >> the definition of "needed" needs revisiting. I think good math and string >> functions certainly qualify. >> >> Cheers, >> Ryan >> >> >> >> On 2017/03/09 11:45 AM, Dominique Devienne wrote: >> >>> I find that I'm often missing basic mathematical functions in the default >>> shell. >>> Many SQLite clients add many, but given that the official SQLite shell >>> misses >>> them you can't use them in views for predefined "reports" within the DB >>> file itself, for example. >>> >>> There's [1] which is 50KB, but only a tiny part of that is for math >>> functions, so math functions are only a few KBs away. >>> >>> Adding basic math functions and stddev, median, variance, etc... wouldn't >>> add much, >>> and they could be added to the shell at least, if deemed too big for the >>> amalgamation, >>> but given that many things can be turned on/off in the amalgamation, that >>> would be just >>> one more IMHO. >>> >>> The goal here would be to move the "minimum expectations" of what can be >>> done with the official shell, out-of-the-box, w/o the need to resort to >>> .load of an extension which is not readily available in compiled form for >>> many non-programmer users. >>> >>> And IMHO, the ability to use math functions in views is why "moving the >>> baseline" is necessary, >>> since without those being built-in, the views will just error out in the >>> official shell. >>> >>> My $0.02, despite the upcoming chorus about lite or do-it-in-your-app >>> naysayers. Thanks, --DD >>> >>> PS: Sure SQLite's primary use case is as an *embedded* DB, so the host-app >>> can add >>> whatever it wants/needs in terms of UDFs, but I also think the >>> "standalone" >>> use of SQLite independently of the app that generated the DB file is >>> important, and we should raise the >>> bar of the minimum number of built-in functions, starting with the >>> official >>> shell. >>> >>> [1] https://www.sqlite.org/contrib/download/extension-functions.c?get=25 >>> _______________________________________________ >>> sqlite-users mailing list >>> sqlite-users@mailinglists.sqlite.org >>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >>> >> >> _______________________________________________ >> sqlite-users mailing list >> sqlite-users@mailinglists.sqlite.org >> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >> > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
