Problems adding 'eval' and 'csv' extensions to the shell
(1) By anonymous on 2020-09-05 19:41:02 [link] [source]
Inspired by check-in [fc0856dccf] I tried the same with 'eval' and 'csv'. That did not work as planned. Adding 'eval' failed on a collision of the 'callback' function defined earlier in the amalgamation. Changing the name of this function in 'eval' to 'evcallback' fixed this. Similarly adding 'csv' failed on a collision of the 'csv_read_one_field' function defined earlier in the amalgamation. Changing the name of this function in 'csv' to 'csvx_read_one_field' fixed this. Could someone make these changes so that future attempts by others will not fail?
(2) By Keith Medcalf (kmedcalf) on 2020-09-05 22:22:27 in reply to 1 [link] [source]
Yes please. And to note, the name collisions are with the shell.c code, not the amalgamation.
I still continue to wonder why extensions are being added to the "shell" diagnostic tool application rather than the sqlite3.c core amalgamation where they would be available not only to the diagnostic "shell" application but to everything that uses the sqlite3.c core (with appropriate enablements) including the diagnostic shell? There are only a very few that are only relevant to the shell application itself or that I haven't gotten around to extricating yet (completion, appendvfs, memtrace, sqlite3expert, dbdata).
Every time an extension is added to the shell I have to remove it so that I can add it to the core where it belongs; or am I the only one that finds it annoying that functionality is available in the diagnostic shell (that are not shell commands) that are not available in the core?
Note that having done this (added every extension plus several of my own, except the ones noted above, to the amalgamation) the size of sqlite3.c is (for me) now more than 10 MB however this does mean that all extensions and virtual tables are available everywhere that is built with the core (sqlite3.c amalgamation) including, for example, pysqlite2 and APSW, as well as to the shell.
I haven't created the defines necessary to allow choice as to which ones are included though so by default most of them are.
(3) By Larry Brasfield (LarryBrasfield) on 2020-09-05 22:49:42 in reply to 2 [source]
A related topic was discussed here, recently. It is not clear to me that having lots (or all) of the extensions (now published beside the SQLite source) embedded in the amalgamation is a good idea. There is a separation-of-concerns argument against doing so.
I also like having a CLI shell with lots of extensions available without having to .load anything. (I have appreciated and used your collection of extensions.) But I do not find it annoying that the SQLite library itself is restricted to a narrower purpose than the ever-expanding shell seems to have.
As suggested in that other thread, a good compromise would be for a gob_of_extensions.c to exist which would #include everything needed from the extensions source subtree, with omissions controlled by #ifdef constructs. That might even become the shell's way of including extensions, which could alleviate your annoyance.