On 2019/05/23 1:26 PM, J. King wrote:
On May 23, 2019 6:46:52 a.m. EDT, R Smith <ryansmit...@gmail.com> wrote:
This is SQLite. Perhaps some of us could collaborate on a fork called
SQLbloat //..
I find this a little condescending. There's a lot of reasons to like SQLite, and the aspect that
sways me more than others is not "lite", but "zeroconf".
I mainly use SQLite in PHP and Tcl, so using my own SQLite library is often not
practical, and in the case of PHP, loadable extensions are disabled by default.
I as a programmer am at the mercy of what distributions package---which is
often SQLite in its default configuration, so a less-lite-but-still-zeroconf
SQLessLite as the default configuration would be extremely valuable to me. At
the same time, those working in tiny systems still have tons of compile-time
options to keep things lean.
In short, I'm skeptical that the choices Hwaci have made about what to exclude are
necessarily beyond reproach or discussion. Derogatory references to "SQLbloat"
really don't further the cause of honest discussion.
This is a misunderstanding of my intent, much as the OP misunderstood
that I don't consider a function that could confirm the presence of
another function to be bloat, I quite welcome that, and I most certainly
do not think any decision is beyond reproach. The entire bloat argument
is towards the extent of the libraries included automatically.
And to be clear, I don't think the Math lib would specifically be bloat,
though it's an unneeded piece of added weight for my needs, but I will
accept it happily if it makes most other people happy. But then, if we
start with the math lib, what is next? Sure enough someone will come up
with a very valid next bit to be added, and a next. I understand that
Richard's decision on inclusion is not beyond reproach, but whose would be?
Put another way, let's say we do add some libraries automatically,
pushing the weight up a nice bit, but they are not the libs you wanted,
would you be happy and consoled? If not, how do you expect anyone else
to be happy with your choice being the chosen implemented? Would you
then rather go back to how it was before?
Lastly, it is very easy to add things to the base distro, but extremely
hard to impossible to ever take it away again, which means one should
only ever "add" with great caution.
Everybody's needs are different and it is impossible to satisfy all, so
I maintain that providing the base SQL functions and having the options
for added functionality relegated to every user's personal choice (with
multiple ways of achieving it no less) is a good solution.
I do however think that having the function-list pragma in the base
distro is needed. Understanding dependency shortcomings would then be as
easy as a quick query, which is especially useful where SQLite is used
through wrappers.
Cheers,
Ryan
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
