CodeVetter · Repo Unpack · Extension points
sqlite/sqlite
SQLite is built almost entirely out of registries, which is why it has such a large third-party ecosystem. At the C level there are seven pluggable interfaces: VFS, virtual-table modules, scalar/aggregate/window functions, collations, page cache, memory allocator, and mutex implementation — plus auto-extensions that fire on every new connection. Above that, FTS5 has its own nested registry for tokenizers and ranking functions. On the source-tree side, the extension points are code generators: adding a PRAGMA means editing `tool/mkpragmatab.tcl`, adding an opcode means adding a `case OP_` in `vdbe.c`, adding grammar means editing `parse.y`, and adding a CLI dot-command means editing the `do_meta_command` chain in `shell.c.in`.
- VFS registry: `sqlite3_vfs_register()`/`sqlite3_vfs_unregister()`/`sqlite3_vfs_find()` form the OS-abstraction plug point, used in-tree by `memdb.c` (the `memdb` VFS) and `os_kv.c` (`kvvfs`), and exported to loadable extensions through the `sqlite3_api_routines` thunk in `loadext.c`.
- Virtual-table registry: `sqlite3_create_module()` and `sqlite3_create_module_v2()` in `src/vtab.c:108-130` register a `sqlite3_module` vtable implementation; this is how `series`, `zipfile`, `dbstat`, `dbpage`, FTS and R-Tree all attach.
- Function registry: built-ins are installed by `sqlite3RegisterBuiltinFunctions()` (`src/func.c:3368`) from a static `FUNCTION(...)` macro table, and the same mechanism is exposed publicly as `sqlite3_create_function*` — extensions like `decimal.c`, `base85.c` and `shathree.c` use it exclusively.
- Collation registry: `createCollation()` (`src/main.c:2907`) backs `sqlite3_create_collation*`; SQLite seeds four built-ins — BINARY in UTF8/UTF16BE/UTF16LE, plus NOCASE and RTRIM — at connection open.
- Auto-extension registry: `sqlite3_auto_extension()` appends to the process-global `sqlite3Autoext` list guarded by `SQLITE_MUTEX_STATIC_MAIN`, and `sqlite3AutoLoadExtensions()` replays it on every new connection.
- Loadable-extension ABI: `sqlite3LoadExtension` looks for `sqlite3_extension_init`, and if absent derives a name of the form `sqlite3_X_init` from the filename between the last `/` and the first `.`, lowercasing alphabetic characters — this is the convention every `ext/misc/*.c` file follows.
- FTS5 exposes a second-level registry through `fts5_api`: `xCreateTokenizer`, `xCreateTokenizer_v2` (for custom text segmentation) and `xCreateFunction` (for auxiliary/ranking functions receiving an `Fts5ExtensionApi`).
- Pluggable subsystem hooks are set through `sqlite3_config()` (`src/main.c:443`), which accepts `SQLITE_CONFIG_MALLOC`, `SQLITE_CONFIG_PAGECACHE`, `SQLITE_CONFIG_MUTEX`, `SQLITE_CONFIG_LOG`, `SQLITE_CONFIG_URI` and threading modes — the CLI itself uses the LOG, URI and MULTITHREAD forms.
- PRAGMA extension point: new pragmas are declared as `NAME:`/`TYPE:`/`ARG:`/`IF:` records in the `pragma_def` block of `tool/mkpragmatab.tcl`, which regenerates `pragma.h`; the matching `case PragTyp_XXXXX:` is then added in `src/pragma.c`.
- Grammar extension point: SQL syntax changes go in `src/parse.y` (2,169 lines), compiled by the in-tree Lemon generator `tool/lemon.c` against the `tool/lempar.c` template — never by editing `parse.c`.
- Shell extension point: `src/shell.c.in` supports an `SQLITE_SHELL_EXTFUNCS` preprocessing hook in `open_db()` for downstream builds to register their own functions, alongside the `INCLUDE ../ext/...` mechanism processed by `tool/mkshellc.tcl`.
- Authorizer hook: `sqlite3_set_authorizer()` (`src/auth.c:70`) installs a callback consulted by `sqlite3AuthCheck`/`sqlite3AuthRead` at code-generation time — `sqlite3Select` calls `sqlite3AuthCheck(pParse, SQLITE_SELECT, …)` before compiling any query — which is the hook the shell's `.auth` and safe mode both build on.
- Build-system extension point: `--amalgamation-extra-src` is threaded through `auto.def` into `AMALGAMATION_EXTRA_SRC`, letting downstream builds fold additional C files into the generated `sqlite3.c`.
- TCL binding extension point: `Sqlite3_Init` registers the `sqlite3` TCL command via `DbMain`, whose per-database object command `DbObjCmd` is the dispatch table that all 1,195 `.test` scripts drive.