Files of check-in [605907e7] in the top-level directory
SQLite Source Repository
This repository contains the complete source code for the SQLite database engine. Some test scripts are also include. However, many other test scripts and most of the documentation are managed separately.
If you are reading this on a Git mirror someplace, you are doing it wrong. The official repository is better. Go there now.
Obtaining The Code
SQLite sources are managed using the Fossil, a distributed version control system that was specifically designed to support SQLite development. If you do not want to use Fossil, you can download tarballs or ZIP archives as follows:
For other check-ins, substitute an appropriate branch name or tag or hash prefix for "release" in the URLs of the previous bullet. Or browse the timeline to locate the check-in desired, click on its information page link, then click on the "Tarball" or "ZIP Archive" links on the information page.
If you do want to use Fossil to check out the source tree, first install Fossil version 2.0 or later. (Source tarballs and precompiled binaries available here.) Then run commands like this:
mkdir ~/sqlite cd ~/sqlite fossil clone https://www.sqlite.org/src sqlite.fossil fossil open sqlite.fossil
After setting up a repository using the steps above, you can always update to the lastest version using:
fossil update trunk ;# latest trunk check-in fossil update release ;# latest official release
Or type "fossil ui" to get a web-based user interface.
See the makefile for additional targets.
SQLite does not require Tcl to run, but a Tcl installation is required by the makefiles (including those for MSVC). SQLite contains a lot of generated code and Tcl is used to do much of that code generation. The makefiles also require AWK.
Source Code Tour
Most of the core source files are in the src/ subdirectory. But src/ also contains files used to build the "testfixture" test harness; those file all begin with "test". And src/ contains the "shell.c" file which is the main program for the "sqlite3.exe" command-line shell and the "tclsqlite.c" file which implements the bindings to SQLite from the Tcl programming language. (Historical note: SQLite began as a Tcl extension and only later escaped to the wild as an independent library.)
Test scripts and programs are found in the test/ subdirectory. There are other test suites for SQLite (see How SQLite Is Tested) but those other test suites are in separate source repositories.
Generated Source Code Files
The SQLite interface is defined by the sqlite3.h header file, which is generated from src/sqlite.h.in, ./manifest.uuid, and ./VERSION. The Tcl script at tool/mksqlite3h.tcl does the conversion. The manifest.uuid file contains the SHA1 hash of the particular check-in and is used to generate the SQLITE_SOURCE_ID macro. The VERSION file contains the current SQLite version number. The sqlite3.h header is really just a copy of src/sqlite.h.in with the source-id and version number inserted at just the right spots. Note that comment text in the sqlite3.h file is used to generate much of the SQLite API documentation. The Tcl scripts used to generate that documentation are in a separate source repository.
The SQL language parser is parse.c which is generate from a grammar in the src/parse.y file. The conversion of "parse.y" into "parse.c" is done by the lemon LALR(1) parser generator. The source code for lemon is at tool/lemon.c. Lemon uses a template for generating its parser. A generic template is in tool/lempar.c, but SQLite uses a slightly modified template found in src/lempar.c.
Lemon also generates the parse.h header file, at the same time it generates parse.c. But the parse.h header file is modified further (to add additional symbols) using the ./addopcodes.awk AWK script.
The opcodes.h header file contains macros that define the numbers corresponding to opcodes in the "VDBE" virtual machine. The opcodes.h file is generated by the scanning the src/vdbe.c source file. The AWK script at ./mkopcodeh.awk does this scan and generates opcodes.h. A second AWK script, ./mkopcodec.awk, then scans opcodes.h to generate the opcodes.c source file, which contains a reverse mapping from opcode-number to opcode-name that is used for EXPLAIN output.
The amalgamation source file is more than 100K lines long. Some symbolic debuggers (most notably MSVC) are unable to deal with files longer than 64K lines. To work around this, a separate Tcl script, tool/split-sqlite3c.tcl, can be run on the amalgamation to break it up into a single small C file called sqlite3-all.c that does #include on about five other files named sqlite3-1.c, sqlite3-2.c, ..., sqlite3-5.c. In this way, all of the source code is contained within a single translation unit so that the compiler can do extra cross-procedure optimization, but no individual source file exceeds 32K lines in length.
How It All Fits Together
Unfortunately, years of effort have gone into optimizating SQLite, both for small size and high performance. And optimizations tend to result in complex code. So there is a lot of complexity in the SQLite implementation.
sqlite.h.in - This file defines the public interface to the SQLite library. Readers will need to be familiar with this interface before trying to understand how the library works internally.
sqliteInt.h - this header file defines many of the data objects used internally by SQLite.
parse.y - This file describes the LALR(1) grammer that SQLite uses to parse SQL statements, and the actions that are taken at each step in the parsing process.
where.c - This file analyzes the WHERE clause and generates virtual machine code to run queries efficiently. This file is sometimes called the "query optimizer". It has its own private header file, whereInt.h, that defines data objects used internally.
btree.c - This file contains the implementation of the B-Tree storage engine used by SQLite.
pager.c - This file contains the "pager" implementation, the module that implements transactions.
shell.c - This file is not part of the core SQLite library. This is the file that, when linked against sqlite3.a, generates the "sqlite3.exe" command-line shell.
tclsqlite.c - This file implements the Tcl bindings for SQLite. It is not part of the core SQLite library. But as most of the tests in this repository are written in Tcl, the Tcl language bindings are important.
There are many other source files. Each has a suscinct header comment that describes its purpose and role within the larger system.