d8075aa07d
This commit turns complex `or` -- `or`s in which not all variables are unified, or in which not all arms are the same shape -- into a computed table. We do this by building a template CC that shares some state with the destination CC, applying each arm of the `or` to a copy of the template as if it were a standalone query, then building a projection list and creating a `ComputedTable::Union`. This is pushed into the destination CC's `computed_tables` list. Finally, the variables projected from the UNION are bound in the destination CC, so that unification occurs, and projection of the outermost query can use bindings established by the `or-join`. This commit includes projection of type codes from heterogeneous `UNION` arms: we compute a list of variables for which a definite type is unknown in at least one arm, and force all arms to project either a type tag column or a fixed type. It's important that each branch of a UNION project the same columns in the same order, hence the projection of fixed values. The translator is similarly extended to project the type tag column name or the known value_type_tag to support this. Review comment: clarify union type extraction. |
||
|---|---|---|
| .. | ||
| 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.