Module vtab 

What the front end has to know about a virtual table.

Invariant: this file holds the data of the virtual-table contract and none of its behaviour. The planner has to be able to say “here are the constraints I can offer and the order I would like”, and the catalog has to be able to hold the columns a module declared, and neither of those can wait until the layer that owns modules. The traits a module implements live above this, in inillucent-ext, where a pager can be named.

The split is not bureaucratic: it is what lets a bound statement stay a pure function of its SQL and one catalog generation. A planner that had to call into a module to describe a plan would be a planner whose output depended on run-time state.

Structs

ConstraintSpec

One constraint the query offers the module.

ConstraintUsage

What the module decided to do with one constraint.

Declaration

What a module says its table looks like.

DeclaredColumn

One column a module declares.

FilterPlan

What filter is told to do.

IndexQuery

The question put to a module’s best_index, and the answer written back.

ModuleArguments

Everything a module is handed when it is connected.

ModuleRef

The module one virtual table is implemented by.

OrderSpec

One ORDER BY term the query offers the module.

ShadowRoot

The root page of one shadow table, by the suffix that names it.

ShadowTable

What a module needs created before it can be connected.

Enums

Change

One row a write asks a module to make.

ConstraintOp

The comparison a constraint applies.

Constants

ROWID_COLUMN

The column number that names the rowid rather than a declared column.

Traits

ShadowStore

The rows of a module’s shadow tables, whatever engine holds them.

Functions

key_sorts_below

Returns whether a keyed row’s leading columns sort before from, compared column by column under inillucent_value::compare::compare_values with BINARY collation - what every shadow table’s key compares under, since none of them declares a column collation of its own.