Module catalog 

Optional schema provider plugged into the resolver.

A Catalog is an enrichment input: structural resolution (CTE / derived table schemas, FROM alias bindings) works catalog-free, and a catalog only fills in the columns — and canonical identity — of real tables the resolver could not derive from the SQL alone. With no catalog those holes stay schema-unknown and surface as Inferred.

It is a concrete, eager registry, not a callback: the consumer builds it up front (typically from an information_schema dump, migration files, or CREATE TABLE statements) and the resolver matches query table references against it. The resolver — not the consumer — owns identifier matching: a query reference matches a registered table by right-anchored, dialect-cased comparison (a bare users matches a registered mydb.users), so consumers don’t reimplement that subtlety.

Open-world. A table the catalog doesn’t contain is taken as schema unknown, not nonexistent — it still surfaces as an ordinary read / write, just Inferred. A misspelled / unregistered table is never flagged at table granularity.

Identifiers are exact. Registered names are the catalog’s ground truth (the stored identifiers), so they compare exactly under case-sensitive dialect folds and fold only under case-insensitive ones — i.e. they behave like quoted identifiers. Register the names as actually stored (e.g. what information_schema reports); the resolver’s dialect-casing policy governs the comparison.

Structs

Catalog

A concrete, eager schema registry. Build it with Catalog::new and Catalog::table (or collect an iterator of CatalogTable), then hand Some(&catalog) to an extractor.

CatalogTable

One table registered in a Catalog: a (catalog?, schema?, name) identity plus its column names.