dbt-labs/dbt-core · error

render_for_create is only available for Databricks/Spark

Error message

render_for_create is only available for Databricks/Spark

What it means

render_for_create renders the column type (including COMMENT clauses) for CREATE TABLE/AS SELECT statements. Only the Databricks and Spark renderers are implemented; any other adapter type falls into the match's catch-all arm and panics with unimplemented!(). It exists because dbt-databricks/dbt-spark need custom type-and-comment rendering during table creation.

Source

Thrown at crates/dbt-adapter/src/column/types.rs:1073

    /// Returns e.g. `` `col` BIGINT NOT NULL COMMENT 'comment' ``
    ///
    /// Reference: https://github.com/databricks/dbt-databricks/blob/822b105b15e644676d9e1f47cbfd765cd4c1541f/dbt/adapters/databricks/column.py#L167-L179
    pub fn render_for_create(&self) -> String {
        match self._adapter_type {
            AdapterType::Databricks | AdapterType::Spark => {
                let mut s = format!("{} {}", self.quoted(), self.data_type());
                if self._nullable == Some(false) {
                    s.push_str(" NOT NULL");
                }
                if let Some(comment) = &self.comment
                    && !comment.is_empty()
                {
                    let escaped = comment.replace('\\', "\\\\").replace('\'', "\\'");
                    s.push_str(&format!(" COMMENT '{escaped}'"));
                }
                s
            }
            _ => unimplemented!("render_for_create is only available for Databricks/Spark"),
        }
    }

    pub fn char_size(&self) -> Option<u32> {
        self.char_size
    }

    pub fn numeric_precision(&self) -> Option<u64> {
        self.numeric_precision
    }

    pub fn numeric_scale(&self) -> Option<u64> {
        self.numeric_scale
    }

    pub fn collation(&self) -> Option<&str> {
        self.collation.as_deref()
    }

View on GitHub (pinned to 0267ce9170)

Solutions

1. Gate the call on adapter type: only render_for_create for Databricks/Spark; use standard type_sql()/DDL rendering elsewhere.
2. For non-Databricks platforms, render the column type via the adapter's default Column::type rendering and append comments with the platform's own syntax.
3. If Spark behavior is intended, ensure the adapter type is set to Databricks or Spark in the relation/column context.

Example fix

// before
let col_ddl = column.render_for_create();

// after
let col_ddl = match adapter_type {
    AdapterType::Databricks | AdapterType::Spark => column.render_for_create(),
    _ => column.type_sql().to_string(),
};

let supported = matches!(adapter_type, AdapterType::Databricks | AdapterType::Spark);
if !supported { /* use default type rendering */ }

fn supports_render_for_create(t: &AdapterType) -> bool { matches!(t, AdapterType::Databricks | AdapterType::Spark) }

When it happens

Trigger: Invoking DbtColumn::render_for_create while adapter_type is anything besides Databricks or Spark — e.g. rendering column DDL on Postgres, Snowflake, Redshift, or BigQuery.

Common situations: A table-creation macro (e.g. custom create_table_as or column comment handling) that calls render_for_create regardless of platform; porting Spark/Databricks model DDL generation to another adapter; tests constructing columns without setting the adapter type.

Related errors

• {type(df)} is not a supported type for dbt Python materializ
• DatabricksAdapter::list_relations_schemas_by_patterns
• not yet implemented
• only available with Databricksadapter
• only available with Databricks adapter

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