08d2c613a4
This commit: - Defines a new kind of column, distinct from the eavt columns in `DatomsColumn`, to model the rows projected from subqueries. These always name one of two things: a variable, or a variable's type tag. Naturally the two cases are thus `Variable` and `VariableTypeTag`. These are cheap to clone, given that `Variable` is an `Rc<String>`. - Defines `Column` as a wrapper around `DatomsColumn` and `VariableColumn`. Everywhere we used to use `DatomsColumn` we now allow `Column`: particularly in constraints and projections. - Broadens the definition of a table list in the intermediate "query-sql" representation to include a SQL UNION. A UNION is represented as a list of queries and an alias. - Implements translation from a `ComputedTable` to the query-sql representation. In this commit we only project vars, not type tags. Review comment: discuss bind_column_to_var for ValueTypeTag. Review comment: implement From<Vec<T>> for ConsumableVec<T>. |
||
|---|---|---|
| .. | ||
| src | ||
| Cargo.toml | ||
| README.md | ||
This crate turns a parsed query, as defined by the query crate and produced by the query-parser crate, into an algebrized tree, also called a query processor tree.
This is something of a wooly definition: a query algebrizer in a traditional relational database is the component that combines the schema — including column type constraints — with the query, resolving names and that sort of thing. Much of that work is unnecessary in our model; for example, we don't need to resolve column aliases, deal with table names, or that sort of thing. But the similarity is strong enough to give us the name of this crate.
The result of this process is traditionally handed to the query optimizer to yield an execution plan. In our case the execution plan is deterministically derived from the algebrized tree, and the real optimization (such as it is) takes place within the underlying SQLite database.