dbt-labs/dbt-core · error

only available with Postgres and Redshift adapters

Error message

only available with Postgres and Redshift adapters

What it means

`relation_max_name_length` is a stub on the generic AdapterImpl that deliberately panics via `unimplemented!` with the note that the maximum relation name length is only available with the Postgres and Redshift adapters. The Rust Fusion adapter has not ported this capability for other engines, so any call on a non-Postgres/Redshift adapter aborts the process/thread. It signals 'this API surface exists but is unimplemented for your adapter', not a runtime failure of your SQL.

Source

Thrown at crates/dbt-adapter/src/adapter/adapter_impl.rs:4786

        let tags = (&ColumnTagsLoader as &dyn ComponentConfigLoader<DatabricksRelationMetadata>)
            .from_local_config(model)?;
        Ok(tags.to_jinja())
    }
    /// Trims surrounding whitespace and strips a single trailing semicolon.
    ///
    /// DatabricksAdapter https://github.com/databricks/dbt-databricks/blob/2f11abb306a400cde32b27891b766bf41a11fb1f/dbt/adapters/databricks/impl.py#L966
    pub fn clean_sql(&self, sql: &str) -> AdapterResult<String> {
        debug_assert!(
            self.adapter_type() == Databricks,
            "clean_sql is a Databricks-specific adapter operation"
        );
        Ok(crate::relation::databricks::config::components::query::clean_sql(sql))
    }

    /// relation_max_name_length
    pub fn relation_max_name_length(&self) -> AdapterResult<u32> {
        unimplemented!("only available with Postgres and Redshift adapters")
    }

    /// This uses the BigQuery SDK's copy_table API instead of SQL to properly handle partitioned
    /// tables.
    /// Reference: https://cloud.google.com/python/docs/reference/bigquery/latest/google.cloud.bigquery.client.Client.html#google_cloud_bigquery_client_Client_copy_table
    ///
    /// BigQueryAdapter https://github.com/dbt-labs/dbt-adapters/blob/0efd8d3d1081e1ab43e38797d5104f7b424a6284/dbt-bigquery/src/dbt/adapters/bigquery/impl.py#L510
    pub fn copy_table(
        &self,
        state: &State,
        conn: &'_ mut dyn Connection,
        source: &Arc<dyn BaseRelation>,
        dest: &Arc<dyn BaseRelation>,
        materialization: String,
        token: CancellationToken,
    ) -> AdapterResult<()> {
        match self.adapter_type() {
            Bigquery => {

View on GitHub (pinned to 0267ce9170)

Solutions

1. Avoid calling relation_max_name_length on non-Postgres/Redshift adapters; hardcode or approximate the max length per target warehouse in your macro.
2. Guard the call with an adapter-type check (adapter.type() in ['postgres','redshift']) and provide a fallback value otherwise.
3. If you need this for another adapter, file/track an upstream feature request to implement relation_max_name_length for that engine.

Example fix

// before
{% set max_len = adapter.relation_max_name_length() %}
// after
{% set max_len = 63 if adapter.type() in ['postgres','redshift'] else 255 %}

// Rust
fn supports_max_name_len(t: &AdapterType) -> bool {
    matches!(t, AdapterType::Postgres | AdapterType::Redshift)
}

let max_len = if supports_max_name_len(&adapter.adapter_type()) {
    Some(adapter.relation_max_name_length())
} else { None };

// Jinja (macros cannot catch panics; guard instead)
{% if adapter.type() in ['postgres', 'redshift'] %}
  {% set max_len = adapter.relation_max_name_length() %}
{% else %}
  {% set max_len = 255 %}
{% endif %}

When it happens

Trigger: Calling `adapter.relation_max_name_length()` (typically from a macro or Jinja helper that queries the max identifier length) while the active adapter type is anything other than Postgres or Redshift — e.g. Snowflake, BigQuery, Databricks, DuckDB.

Common situations: Porting a dbt project from Postgres/Redshift to another warehouse whose macros call relation_max_name_length; running cross-adapter macro code that assumes the Python adapter behavior; testing adapter-agnostic SQL generation paths.

Related errors

• parse_index
• Trino
• Datafusion
• Dremio
• Oracle

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