Struct Pushdown 

pub struct Pushdown {
    pub sql: String,
    pub order_table: Option<String>,
    pub join_left: Option<(String, Vec<String>)>,
    pub column_types: ColumnTypes,
    pub tables: Vec<String>,
}

A pushdown plan: SQL whose execution is provably identical to the Quarb query’s — plus the table whose primary key must order the rows (None for a single aggregate row, where order is moot). The driver appends the ORDER BY, since the key lives in its catalog.

Fields

sql: String

order_table: Option<String>

join_left: Option<(String, Vec<String>)>

Present when the plan contains a witness JOIN: the joined table and the columns its ON equalities bind on it (collected structurally from the arbor, so query text cannot spoof them). The plan is only sound if those columns form a unique key of the joined table — each FROM row must find at most one witness, else SQL multiplies rows where Quarb’s existential binding does not. The driver must verify against its catalog before executing, and fall back to the scan if it cannot.

column_types: ColumnTypes

What the plan takes for granted about column types. Quarb compares by value (a numeric-looking text and a number meet as numbers, a number and other text never meet); SQL compares by the column’s type, and the loosely typed engines (SQLite, MySQL) coerce by rules of their own. The plan is the scan’s only where the columns it compares with a number are numeric-typed and those it compares with text are not: the caller asks its catalog and scans when one is otherwise. (A strictly typed engine rejects the mismatch itself, which sends the caller to the scan as well.)

tables: Vec<String>

The tables the plan reads (the FROM table, then a joined one).