risingwavelabs/risingwave · error

column type mismatch: {:?} vs {:?}, column name: {:?}

Error message

column type mismatch: {:?} vs {:?}, column name: {:?}

What it means

`derive_sink_to_table_expr` returns a user-facing `bail!` error when the sink query's output column type does not exactly match the target table column's type. When sinking into a table, RisingWave only auto-inserts when types are identical (it builds a cast project elsewhere); here, in the default-column projection path, an exact-match check guards the expression derivation and rejects mismatches with both types and the column name.

Source

Thrown at src/frontend/src/handler/create_sink.rs:961

        sinks.push(
            schema
                .get_sink_by_id(*sink_id)
                .expect("should exist")
                .clone(),
        );
    }
    Ok(sinks)
}

fn derive_sink_to_table_expr(
    sink_schema: &Schema,
    idx: usize,
    target_type: &DataType,
) -> Result<ExprImpl> {
    let input_type = &sink_schema.fields()[idx].data_type;

    if !target_type.equals_datatype(input_type) {
        bail!(
            "column type mismatch: {:?} vs {:?}, column name: {:?}",
            target_type,
            input_type,
            sink_schema.fields()[idx].name
        );
    } else {
        Ok(ExprImpl::InputRef(Box::new(InputRef::new(
            idx,
            input_type.clone(),
        ))))
    }
}

pub(crate) fn derive_default_column_project_for_sink(
    sink: &SinkCatalog,
    sink_schema: &Schema,
    columns: &[ColumnCatalog],
    user_specified_columns: bool,

View on GitHub (pinned to 6469eb736d)

Solutions

1. Cast columns explicitly in the sink query: `CREATE SINK s AS SELECT CAST(a AS BIGINT) AS a, ...`.
2. Recreate the target table with types matching the source query.
3. Align vector dimensions by using `VECTOR(n)` of the same n on both sides.
4. Check types on both sides via `information_schema.columns` before creating the sink.

Example fix

// before
CREATE SINK s AS SELECT id, qty FROM src INTO tgt; -- qty INTEGER vs tgt.qty BIGINT
// after
CREATE SINK s AS SELECT id, CAST(qty AS BIGINT) AS qty FROM src INTO tgt;

-- compare source query column types with target table before creating the sink
SELECT column_name, data_type FROM information_schema.columns WHERE table_name = 'src';
SELECT column_name, data_type FROM information_schema.columns WHERE table_name = 'tgt';

When it happens

Trigger: `CREATE SINK ... INTO <table>` where a column of the sink query has a different type than the corresponding target table column and the type cannot be matched — e.g. `INTEGER` vs `BIGINT`, `VARCHAR` vs `INTEGER`, or different `VECTOR(n)` dimensions reaching this helper from `derive_default_column_project_for_sink`.

Common situations: Sinking into a table created with different column types than the source; target table altered after the sink query was written; decimals/timestamps with different precision; vector columns of mismatched dimension.

Understand the failure class

Background: Type mismatch errors: IllegalArgumentException, TypeError and type guards across 150 open-source libraries — this error's family across 150 libraries.

Related errors

• missing FORMAT ... ENCODE ...
• The key encode is BYTES, but the primary key column {} has t
• ENCODE BYTES requires the column to be of type BYTEA, but go
• The key encode is TEXT, but the primary key column {} has ty
• HTTP sink url column must be varchar, got {:?}

AI-assisted analysis of risingwavelabs/risingwave@6469eb736d (2026-09-11). Data as JSON: /api/errors/4048bcb81b2ab319. Report an issue: GitHub.