Trait Rows 

pub trait Rows {
    // Required method
    fn scan(&self, table: &Table) -> Result<Vec<Value>, SqlError>;

    // Provided methods
    fn count(&self, table: &Table) -> Result<Option<u64>, SqlError> { ... }
    fn backend(&self) -> Option<&dyn Backend> { ... }
}

Where a table’s rows come from. Implemented by whoever holds the running program.

Required Methods

fn scan(&self, table: &Table) -> Result<Vec<Value>, SqlError>

Every row of one table, in the order the collection holds them.

Provided Methods

fn count(&self, table: &Table) -> Result<Option<u64>, SqlError>

How many rows there are, if that can be answered without building them.

23 §23.19: “count(*) without scanning — not built. The plan’s list_len is ±1 per delta; the SQL count is over the rows it scanned.” This is the seam that closes it. A maintained arrangement and a Map in the accumulator each know their size, so a query whose whole answer is a number should not clone every value and build a Cell for every column of every one.

None means “not without a scan”, and the caller falls back — so an implementation that does not override this is correct and merely as slow as it was. That default is the point: the seam cannot make a reader wrong, only faster.

fn backend(&self) -> Option<&dyn Backend>

The backend a relational query’s operators are prepared against.

A join, a group by and a distinct are compiled into a crate::plan::Plan and run by crate::engine rather than interpreted here (docs/99 §99.9 item 9), and preparing a plan means turning its per-element functions into crate::backend::Callables — which is a backend’s job and not this module’s.

None is the honest answer for a reader with no executor behind it: those three queries are refused with a message saying so, and every other query is answered exactly as before. The default is None for Rows::count’s reason — a seam may make a reader faster or narrower, never wrong.

Implementors