dbt-labs/dbt-core · error · IndexError
' ' is not a column of
Error message
'{out}' is not a column of '{}' What it means
When generating the SELECT list for an information-schema view, each requested output column must exist in the registered table spec. If a requested column name (out) is not found among spec.cols, create_view_sql fails with this error naming both the column and the underlying table. It prevents generating SQL that would reference a nonexistent column.
Solutions
- Verify each requested column name against the spec's declared columns (spec.cols / c.out)
- Upgrade dbt-index-core if the column was introduced in a newer release
- Derive the column list programmatically from the spec instead of hardcoding it
- Fix the typo if a column name was misspelled
Example fix
// before cols: vec!["node_id", "cheksum"] // typo // after cols: vec!["node_id", "checksum"]
Defensive patterns
Strategy: validation
Validate before calling
let declared: Vec<_> = spec.cols.iter().map(|c| c.out.as_str()).collect();
for c in &cols { assert!(declared.contains(&c.as_str()), "unknown column {c}"); } Prevention
- Build column lists from the spec, never hardcoded
- Re-check column names after upgrading index-core
- Lint model/docs column references against the information schema
When it happens
Trigger: Building an information-schema view while requesting a column (self.cols entry) that the registered spec for the vocabulary does not declare — e.g. a typo, a column added in a newer schema version, or mixing column sets across vocabularies.
Common situations: A caller constructs the column list from a stale or hand-written list instead of the spec; upgrading index-core renamed or removed a column; copying a column list from a different information-schema table.
Understand the failure class
Background: "Must be a positive integer", "Invalid value", "Unsupported": the invalid-argument-value error family, when a library rejects the value you pass — this error's family across 35 libraries.
Related errors
- no information-schema table named
- clean_sql
- Detected columns with numeric type and unspecified…
- events_last_year should compile without error
- invalid return value
AI-assisted analysis of dbt-labs/dbt-core@0267ce9170 (2026-09-07).
Data as JSON: /api/errors/ac6b3b7df82cd715.
Report an issue: GitHub.
Appendix: source
Thrown at crates/dbt-index-core/src/info_schema/parse_safe.rs:652
// Assembled rather than projected. `info_schema::build_own` and
// `epoch_views::own_sql` special-case the same table by name; this is the third
// place that has to, for the same reason.
if matches!(self.src, Src::Own) {
return self.dag_nodes_sql();
}
let spec = spec_for(Ns::Dbt, self.vocabulary).ok_or_else(|| {
self.err(format!(
"no information-schema table named '{}'",
self.vocabulary
))
})?;
let mut selects = Vec::with_capacity(self.cols.len());
for out in self.cols {
let col =
spec.cols.iter().find(|c| c.out == *out).ok_or_else(|| {
self.err(format!("'{out}' is not a column of '{}'", spec.name))
})?;
// A column the information schema declares but assembles in code has no
// source name to borrow; the index column is the one that shares its name.
let src = if col.src.is_empty() { col.out } else { col.src };
selects.push(format!("{} AS {}", self.qualify(src)?, quote(out)));
}
let from = match self.src {
Src::Table(table) => format!("{BASE_SCHEMA}.{} AS {T}", quote(table)),
Src::Join {
left,
right,
left_on,
right_on,
} => format!(
"{BASE_SCHEMA}.{} AS {L} LEFT JOIN {BASE_SCHEMA}.{} AS {R} ON {L}.{} = {R}.{}",
quote(left),
quote(right),View on GitHub (pinned to 0267ce9170)