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
