Module table_source 

The server-side leaf [Source]: a Source backed by a SQLite table (the server-side replica of Postgres). Production port of packages/zqlite/src/table-source.ts (class TableSource), the peer of the client-side MemorySource. It owns three things (05 §1.1):

1. The leaf scan — a FetchRequest is compiled to a parameterized SELECT (build_select_query) and executed against rusqlite, vending rows lazily and zero-copy: Str/Json values borrow directly from the sqlite3_column_text buffers (valid only until the next step), and a row is materialized exactly once — at the connection boundary — via the borrow checker-forced [RowRef::to_owned_row]. The whole conn→stmt→cursor borrow chain is owned by one OwnedSqliteRows so the lazy stream can be boxed and returned (the 05 §13 Q1 self-reference, solved with one contained, drop-ordered unsafe).
2. Connections + the overlay/push/edit-split machinery — identical to the memory leaf: it reuses the backend-agnostic source_common seam verbatim (generate_with_overlay_checked, [generate_with_start], try_gen_push_and_write_with_split_edit). The leaf only differs in the scan.
3. The write path — INSERT/DELETE/UPDATE, committed after the vend (the self-join correctness invariant, §3.11).

A source emits rows, not nodes (04/05 §1.1): fetch returns a [RowFlow]; the connection boundary (Graph::fetch on a SourceConn) wraps each row in a leaf node. The Node concept lives entirely above this module — exactly as for MemorySource.

Build target: feature = "sqlite" only.

Structs

TableSource

TableSource — the SQLite-backed leaf source. Mirrors MemorySource’s shape: the overlay/push/edit-split machinery is shared; only the leaf scan (a real rusqlite cursor instead of a COW B+tree) and the write path differ.