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
