dbt-labs/dbt-core · error

unknown table type: {type_string}

Error message

unknown table type: {type_string}

What it means

RelationType::from_adapter_type translates a database-reported table type string (e.g. from information_schema) into a RelationType enum. For BigQuery, only a fixed set of type strings is recognized; anything else panics with 'unknown table type'. The library treats an unrecognized catalog type as a hard error instead of guessing a relation kind.

Source

Thrown at crates/dbt-schemas/src/dbt_types.rs:54

    /// An enum for a ClickHouse dictionary
    Dictionary,
}

impl RelationType {
    /// Convert a given type string for a given [AdapterType] to a dbt RelationType
    // TODO: This should return an error instead of panicking.
    pub fn from_adapter_type(adapter_type: AdapterType, type_string: &str) -> Self {
        match adapter_type {
            // https://cloud.google.com/bigquery/docs/information-schema-tables
            // Alternatively, if querying from the Google API:
            // https://docs.cloud.google.com/bigquery/docs/reference/rest/v2/tables
            AdapterType::Bigquery => match type_string.to_uppercase().as_str() {
                "BASE TABLE" | "CLONE" | "SNAPSHOT" | "TABLE" => RelationType::Table,
                "VIEW" => RelationType::View,
                "MATERIALIZED VIEW" | "MATERIALIZED_VIEW" => RelationType::MaterializedView,
                "EXTERNAL" => RelationType::External,
                "FUNCTION" | "AGGREGATE FUNCTION" => RelationType::Function,
                _ => panic!("unknown table type: {type_string}"),
            },
            // https://docs.databricks.com/aws/en/sql/language-manual/information-schema/tables#table-types
            AdapterType::Databricks => match type_string.to_uppercase().as_str() {
                "TABLE" => RelationType::Table,
                "VIEW" => RelationType::View,
                "MATERIALIZED_VIEW" => RelationType::MaterializedView,
                "EXTERNAL" | "EXTERNAL_SHALLOW_CLONE" | "FOREIGN" => RelationType::External,
                "STREAMING_TABLE" => RelationType::StreamingTable,
                "METRIC_VIEW" => RelationType::MetricView,
                "MANAGED" | "MANAGED_SHALLOW_CLONE" => RelationType::Table,
                _ => panic!("unknown table type: {type_string}"),
            },
            AdapterType::Spark => match type_string.to_uppercase().as_str() {
                // These are the only table types Apache Spark's catalog reports
                // (`CatalogTableType`) via `DESCRIBE TABLE EXTENDED`, identical over
                // Thrift/Livy/Spark Connect: MANAGED, EXTERNAL, VIEW (released 3.5/4.0)
                // https://github.com/apache/spark/blob/f0bb2e6a47d0ebda424ffd633fcea8644a597954/sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/catalog/interface.scala#L1039
                "MANAGED" | "EXTERNAL" => RelationType::Table,

View on GitHub (pinned to 0267ce9170)

Solutions

1. Update dbt-schemas to the latest version so new BigQuery table types are mapped
2. Trim the type string and verify exact values returned by BigQuery's INFORMATION_SCHEMA before passing them in
3. Patch/extend the match arm to map the new type (or contribute the mapping upstream)
4. As a stopgap, preprocess the string to a known value when you know the semantic equivalent

Example fix

// before
let rt = RelationType::from_adapter_type(AdapterType::Bigquery, raw_type);

// after
let t = raw_type.trim().to_uppercase();
let known = ["BASE TABLE","CLONE","SNAPSHOT","TABLE","VIEW","MATERIALIZED VIEW","MATERIALIZED_VIEW","EXTERNAL","FUNCTION","AGGREGATE FUNCTION"];
assert!(known.contains(&t.as_str()), "unmapped BigQuery table type: {raw_type}");
let rt = RelationType::from_adapter_type(AdapterType::Bigquery, &t);

const BIGQUERY_KNOWN: &[&str] = &["BASE TABLE","CLONE","SNAPSHOT","TABLE","VIEW","MATERIALIZED VIEW","MATERIALIZED_VIEW","EXTERNAL","FUNCTION","AGGREGATE FUNCTION"];
fn is_known_bigquery_type(t: &str) -> bool {
    BIGQUERY_KNOWN.contains(&t.trim().to_uppercase().as_str())
}

fn valid_table_type(t: &str) -> Option<String> {
    let u = t.trim().to_uppercase();
    if u.is_empty() { None } else { Some(u) }
}

let rt = std::panic::catch_unwind(|| RelationType::from_adapter_type(AdapterType::Bigquery, &t))
    .map_err(|_| format!("unknown BigQuery table type: {t}"))?;

When it happens

Trigger: Calling from_adapter_type with AdapterType::Bigquery and a type_string that uppercases to something outside {BASE TABLE, CLONE, SNAPSHOT, TABLE, VIEW, MATERIALIZED VIEW, MATERIALIZED_VIEW, EXTERNAL, FUNCTION, AGGREGATE FUNCTION} — e.g. a new BigQuery table kind or localized/quoted type output from a metadata query.

Common situations: BigQuery introducing a new relation type not yet mapped in the adapter; hand-written SQL against INFORMATION_SCHEMA.TABLES returning unexpected TABLE_TYPE values; a driver returning empty or differently-cased/whitespace-padded strings.

Related errors

• Schema not found for canonical FQN: {}
• `EnterGuard` values dropped out of order. Guards returned by
• {e} {:?}
• {e}
• inconsistent park state; actual = {actual}

AI-assisted analysis of dbt-labs/dbt-core@0267ce9170 (2026-09-07). Data as JSON: /api/errors/0314e65e3a57b059. Report an issue: GitHub.