First-party lexer, parser, AST, binder, semantic rewrites, and logical and physical plans.
Invariant: the SQL front end is pure. It parses, binds, plans and compiles;
it opens no file, reads no page, and holds no connection. Everything it
needs to know about a schema arrives through [catalog_view::CatalogView],
which is a read-only view someone else has already built.
That interface is why this crate sits below inillucent-catalog rather than
above it. The catalog has to parse the CREATE text stored in
sqlite_schema with this parser, and a crate cannot be both above and below
another; the parser is the more fundamental half, so it goes underneath and
the catalog implements the view.
Module map, in the order SQL moves through them:
- [
keyword] - the pinned release's keyword table and its fallback rule; - [
lexer] - bytes to tokens, zero copy, with spans; - [
precedence] - the operator table, as data; - [
ast] - the arena and every node kind; - [
diagnostic] - syntax failures, with offsets; - [
parser] - recursive descent for statements, Pratt for expressions; - [
catalog_view] - what the binder is allowed to know about a schema; - [
bind] - names to columns, and the bound relational tree; - [
plan] - the logical and physical plans the compiler walks.