risingwavelabs/risingwave · error · anyhow::Error

{:?} data type is not supported

Error message

{:?} data type is not supported

What it means

The PostgreSQL connector does not map every Postgres type to a RisingWave type. `sea_type_to_rw_type` bails with '{:?} data type is not supported' for geometric types (Point, Polygon, Circle), Bit/VarBit, TsVector, TsQuery, and other unmapped types when discovered in the source table.

Source

Thrown at src/connector/src/connector_common/postgres.rs:724

        | SeaType::MacAddr8
        | SeaType::Int4Range
        | SeaType::Int8Range
        | SeaType::NumRange
        | SeaType::TsRange
        | SeaType::TsTzRange
        | SeaType::DateRange
        | SeaType::Enum(_) => DataType::Varchar,
        SeaType::Line
        | SeaType::Lseg
        | SeaType::Box
        | SeaType::Path
        | SeaType::Polygon
        | SeaType::Circle
        | SeaType::Bit(_)
        | SeaType::VarBit(_)
        | SeaType::TsVector
        | SeaType::TsQuery => {
            bail!("{:?} data type is not supported", col_type);
        }
        SeaType::Unknown(name) => {
            if let Some(dim) = parse_pgvector_dimension(name)? {
                DataType::Vector(dim)
            } else if matches!(name.to_ascii_lowercase().as_str(), "geometry" | "geography") {
                DataType::Bytea
            } else {
                // NOTES: user-defined enum type is classified as `Unknown`
                tracing::warn!("unknown PostgreSQL data type `{name}`; mapping it to varchar");
                DataType::Varchar
            }
        }
    };

    Ok(dtype)
}

fn parse_pgvector_dimension(type_name: &str) -> ConnectorResult<Option<usize>> {

View on GitHub (pinned to 6469eb736d)

Solutions

1. Drop or move unsupported columns to a separate table not consumed by RisingWave
2. Cast unsupported columns to supported types in a view (e.g. `bit_col::text`) and CDC from the view where applicable
3. For PostGIS `geometry`/`geography`, keep the name-based mapping which maps them to BYTEA (do not rename to an unmapped type)
4. Track/upvote support for the specific type in RisingWave

Example fix

-- before
CREATE TABLE docs (body tsvector);
-- after
CREATE TABLE docs (body_text text); -- or cast in a view: body::text AS body_ts

const UNSUPPORTED: &[&str] = &["point","polygon","circle","bit","varbit","tsvector","tsquery"];
fn check_pg_columns(cols: &[(String, String)]) -> Result<(), String> {
    for (name, ty) in cols {
        let base = ty.split('(').next().unwrap_or(ty).trim().to_ascii_lowercase();
        if UNSUPPORTED.contains(&base.as_str()) {
            return Err(format!("column {name} uses unsupported type {ty}"));
        }
    }
    Ok(())
}

fn is_supported_pg_type(ty: &str) -> bool {
    let base = ty.split('(').next().unwrap_or(ty).trim().to_ascii_lowercase();
    !("point" | "polygon" | "circle" | "bit" | "varbit" | "tsvector" | "tsquery").matches(base)
}

match sea_type_to_rw_type(&ty) {
    Err(e) if e.to_string().contains("data type is not supported") => {
        // exclude the column, CDC from a view casting it to text, or fail the plan with guidance
        plan.exclude_column(col_name, e);
    }
    r => r?,
}

When it happens

Trigger: `sea_type_to_rw_type` (called from `connect` or recursively for array elements) receiving a column whose SeaType falls into the unsupported match arm — e.g. a column of type `point`, `tsvector`, `bit(8)`, or `varbit`.

Common situations: CDC on a table containing Postgres full-text search columns (tsvector/tsquery), geometry via built-in types rather than PostGIS, bit-string columns, or custom enum types not handled by discovery.

Related errors

• ARRAY type missing element type
• unsupported PostgreSQL snapshot list element type {elem}
• unsupported PostgreSQL snapshot data type {data_type} for co
• failed to convert type {:?} to ScalarAdapter
• BIT({}) type not supported

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