On Thursday, 6 December, 2018 08:23, Nathan Green <[email protected]> wrote:
>On Tue, Dec 4, 2018 at 11:25 AM Digital Dog <[email protected]> wrote: >> On Tue, Dec 4, 2018 at 5:57 PM Richard Hipp <[email protected]> wrote: >> > On 12/4/18, Digital Dog <[email protected]> wrote: >> > > I vote for GENERATE_SERIES to be included in official sqlite3 >> > > binary and libraries. >> > We are under pressure to keep SQLite as small and compact as >> > possible. >> > We cannot go adding every feature that everyone requests without >> > the size of the library growing out of control. Trade-offs have to be >> > made. We try to provide the ability for people who actually want >> > lots of features to include them in their own builds. But we do no >> > think it is appropriate to add things that grow the size of the library >> > unless there is a compelling need. >> Okay - keeping the core library small - that makes sense. >> But for the Command Line tools for general purpose OS like Windows, >> Linux, BSD, macOS which you offer for download? I'm not so sure. It could >> contain more features because there are no restrictions. Windows, macOS, >> typical Linux server or desktop won't work without gigabytes of RAM. Mobile >> devices are joining the club. I think the scenario can be completely >> reversed - majority of platforms is capable enough that they can include >> almost all features, and only some, embedded, esoteric, have real constraints >> and require trimmed feature set. I think they need to be custom-built >> anyway. >> Or maybe it is possible to offer different builds - minimal shell >> and fully-packed shell on the download page? >Yes, generate_series can be simulated, but adding 5 extra lines to a >query is quite unpleasant. Making it an optional flag in the amalgamation >build has no impact on library size unless one takes the extra step to >include it. I've already put together a patch that makes this possible, I >just need to open a pull request I guess. I just don't want to put too >much time into it if it's going to be rejected out of hand. But, if you are going to have an extra compile time flag to enable it, then why not just include the extension when you compile the code yourself since that only requires appending the "extensions" you want included, a custom "init hook" to load them all, and one additional define at compile time to tell SQLite3 to run your additional "init hook" for every connection? And it works the same for adding "internal extensions" to both the shell and the core library? I load a whole mess of extensions this way and have them initialized on every connection, compiled into both the shell and the SQLite3 engine itself. In fact, the most difficult thing to deal with is when extensions are loaded "internally" as part of shell.c but not loaded into the actual sqlite3.c amalgamation code itself since this means I have to find and disable the addition of the extension in shell.c and wrap a bunch of defines around it to disable it from compilation otherwise the optimizer gripes and complains about duplicate symbols and modules, so that I can add it where it belongs, in the sqlite3.c library, so that LTO and page-tuning work properly. Why one would want a particular capability available in the shell that is not available when compiling the amalgamation code directly is beyond my ken. I realize that consistency is the hobgobblin of little minds, but why would one not want the same extensions available when compiling the amalgamation into "some other" application but have that extension built into the shell (which is merely yet another application)? --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
