pub enum ResolutionKind {
Cataloged,
Inferred,
Ambiguous,
Unresolved,
}Expand description
How a reference was resolved — “what kind of resolution backs this
(table, name) placement?”.
Catalog-less mode runs as an inference mode: every real-table binding’s schema is unknown, so a single-candidate resolution is best-effort, not catalog-backed. CTE and derived bodies do carry known schemas (the resolver derives them from the body’s projection), but those refs are synthetic and dropped from the public reads / lineage by the resolver’s post-pass.
Ambiguous and Unresolved are the two failure modes. Both come
with table: None on the ColumnReference; the variant tells
the consumer why the resolver gave up. (Unresolved arises only
for columns — a table reference always has a name present.)
§Invariants
- Catalog-less mode → no public
Cataloged: every surviving non-synthetic ref points at an unknown real table, so the strongest claim the resolver can make isInferred. Catalog-aware analysis is therefore detectable by the presence ofCataloged. - Catalog-aware mode does not imply
Cataloged: catalogs are often partial. Refs against tables the catalog doesn’t cover, or against a real unknown table that won a multi-candidate tiebreaker over known ones, both still come back asInferred.
§How each variant arises
| Situation | ResolutionKind |
|---|---|
| catalog-less, real unknown table, sole candidate | Inferred |
| catalog-less, two real unknown tables in scope | Ambiguous |
| catalog-less, CTE known body confirms the column | (internal Cataloged; synthetic, dropped) |
catalog-less, CTE known body denies the column (SELECT typo FROM cte where cte = [id]) | Unresolved |
| catalog-aware, known binding lists the column | Cataloged |
| catalog-aware, known binding doesn’t list the column | Unresolved |
| catalog-aware, one known confirms + one unknown suspect (known-witness-over-unknown-suspects) | Inferred |
| catalog-aware, two or more known schemas confirm | Ambiguous |
qualified t.col where t is unknown | Inferred |
qualified t.col where t is known and lists col | Cataloged |
§Consumer guidance
- Strict mode validation: a fully resolved, catalog-confirmed
statement satisfies
op.diagnostics.is_empty() && op.reads.iter().all(|r| r.resolution == ResolutionKind::Cataloged). - DFD / CRUD comprehension: treat
CatalogedandInferredinterchangeably as “resolved” (use the(table, name)pair); treatAmbiguousandUnresolvedas “incomplete”. A lineage source is always a written reference (a base column, or anAmbiguous/Unresolvedone withtable: None) — the resolver never fabricates a source named after a statement-local relation (a table function’s output traces to the function’s arguments, aVALUEScolumn to its row cells).
Variants§
Cataloged
Backed by a known schema that lists the column / names the
table. On the public surface this means a catalog (or registry)
entry backed the reference. Internally a CTE / derived body’s
known schema also yields this variant on a synthetic ref, but
the post-pass drops those — so consumers only ever see
Cataloged for catalog-backed real references.
Inferred
Resolution succeeded by assuming the reference exists where the resolver placed it: an unknown-schema binding adopted as the sole candidate, a qualified reference whose qualifier alone determined the table, or a known witness winning over unknown suspects in a multi-candidate scope. All defensible inferences in catalog-less or partial-catalog mode, but not proven.
Ambiguous
Multiple plausible candidates and the resolver couldn’t pick
one: either two-or-more known schemas confirmed the column
(genuine ambiguity), or every candidate was an unknown
suspect with no tiebreaker. ColumnReference.table is None.
Unresolved
No in-scope binding could plausibly own the column: either
every known schema in scope explicitly denied it, or the
scope chain held no bindings at all. ColumnReference.table
is None. Columns only.