It is hereby proposed to add capability to SQLite so that it can load dynamic libraries (DLLs in windows-speak) at run-time under SQL control. This capability would allow SQLite to be extended with new SQL functions, collating sequences, and/or virtual tables and views at run-time, without relinking. So, for example, a user could download the standard SQLite command-line shell from the website and add new features without having to recompile and relink.
The proposed syntax is as follows:
LOAD filename;
Or
LOAD filename(functionname);
The OS-interface layer will need to be enhanced to support run-time loading of dynamic libraries. (This is done using the dlopen()/dlsym() calls in Posix or LoadLibrary()/GetProcAddress() in windows.) Operation systems that do not support dynamic libraries would have stub functions in these slots that return errors.
The "LOAD filename" command would call dlopen() on the specified filename, then use dlsym() to find an initialization procedure based on that filename. The "LOAD filename(proc)" variant of the command would use the "proc" argument as the name of the initialization procedure. The initialization procedure would then be invoked with a single argument when is a pointer to the sqlite3* pointer. The initialization procedure would make various calls to sqlite3_create_function() and sqlite3_create_collation(), etc, in order to add the functionality that the dynamic library implements.
There will also be a C-language API for the loadable library mechanism:
int sqlite3_load_library(
sqlite3*,
const char *zFilename,
const char *zProc
);
The C-language API could be called, for example, by the callback routines of sqlite3_collation_needed(). The collation_needed() callback could then search for and load collating sequences on an as-needed basis. We might also want to add sqlite3_function_needed() and sqlite3_module_needed() APIs that can be employed to search for the implementation of unknown functions and virtual table/view modules on an as needed basis.