rudb_bind/lib.rs
1//! Name, type and overload resolution, subquery binding, and the bound logical plan.
2//!
3//! Rank 10 in the layer rule. See `xtask/layers.toml` and `spec/18-package-layout.md`.
4//!
5//! The binder is the pass that turns what someone wrote into what it means. A parse tree says
6//! `SELECT x FROM t`, and only the binder can say which table `t` is, which column `x` is, what
7//! type it has, and therefore what the query does. Everything after this point works on the
8//! answer rather than on the question: the optimizer never resolves a name and the executor never
9//! decides a type.
10//!
11//! There are two entry points and the difference between them is what they can return. [`bind`]
12//! takes a statement that produces rows and gives back a [`rudb_plan::Plan`], which is what an
13//! optimizer and an executor want. [`bind_statement`] takes any statement and gives back a
14//! [`Bound`], which is a plan for a query and a resolved catalog operation for `CREATE TABLE`,
15//! `DROP TABLE` and `INSERT`. DDL is not a plan node, for the reason `statement.rs` gives.
16//!
17//! What it does not do yet is subqueries, window functions, `WITH`, and every statement outside
18//! those four. Each of those is an error naming what was written rather than a silently wrong
19//! plan, which is the rule the whole front end follows.
20
21#![forbid(unsafe_code)]
22
23mod binder;
24mod expr;
25mod scope;
26mod statement;
27
28pub use binder::{bind, bind_sql};
29pub use statement::{Bound, CreateTable, DropTable, Insert, bind_statement, bind_statement_sql};
30
31#[cfg(test)]
32mod tests;