risingwavelabs/risingwave · error · SinkError::BigQuery

INTERVAL is not supported for BigQuery sink. Please convert

Error message

INTERVAL is not supported for BigQuery sink. Please convert to VARCHAR or other supported types.

What it means

`map_field` rejects `DataType::Interval` because BigQuery has no INTERVAL column type. The sink instructs users to convert INTERVAL data to VARCHAR or another supported type rather than guessing a serialization.

Source

Thrown at src/connector/src/sink/big_query.rs:458

        let tfs = match &rw_field.data_type {
            DataType::Boolean => TableFieldSchema::bool(&rw_field.name),
            DataType::Int16 | DataType::Int32 | DataType::Int64 | DataType::Serial => {
                TableFieldSchema::integer(&rw_field.name)
            }
            DataType::Float32 => {
                return Err(SinkError::BigQuery(anyhow::anyhow!(
                    "REAL is not supported for BigQuery sink. Please convert to FLOAT64 or other supported types."
                )));
            }
            DataType::Float64 => TableFieldSchema::float(&rw_field.name),
            DataType::Decimal => TableFieldSchema::numeric(&rw_field.name),
            DataType::Date => TableFieldSchema::date(&rw_field.name),
            DataType::Varchar => TableFieldSchema::string(&rw_field.name),
            DataType::Time => TableFieldSchema::time(&rw_field.name),
            DataType::Timestamp => TableFieldSchema::date_time(&rw_field.name),
            DataType::Timestamptz => TableFieldSchema::timestamp(&rw_field.name),
            DataType::Interval => {
                return Err(SinkError::BigQuery(anyhow::anyhow!(
                    "INTERVAL is not supported for BigQuery sink. Please convert to VARCHAR or other supported types."
                )));
            }
            DataType::Struct(st) => {
                let mut sub_fields = Vec::with_capacity(st.len());
                for (name, dt) in st.iter() {
                    let rw_field = Field::with_name(dt.clone(), name);
                    let field = Self::map_field(&rw_field)?;
                    sub_fields.push(field);
                }
                TableFieldSchema::record(&rw_field.name, sub_fields)
            }
            DataType::List(lt) => {
                let inner_field =
                    Self::map_field(&Field::with_name(lt.elem().clone(), &rw_field.name))?;
                TableFieldSchema {
                    mode: Some("REPEATED".to_owned()),
                    ..inner_field

View on GitHub (pinned to 6469eb736d)

Solutions

Cast the INTERVAL column to VARCHAR in the view feeding the sink.
Convert the interval to a numeric duration (e.g. EXTRACT(EPOCH ...) or seconds) and sink that as INT64/FLOAT64.
Restructure the query to avoid producing INTERVAL columns (store start/end timestamps instead).

Example fix

-- before
CREATE MATERIALIZED VIEW mv AS SELECT (end_ts - start_ts) AS duration FROM events;

-- after
CREATE MATERIALIZED VIEW mv AS SELECT EXTRACT(EPOCH FROM (end_ts - start_ts)) AS duration_seconds FROM events;

Defensive patterns

Strategy: validation

Validate before calling

-- Find INTERVAL columns before sinking:
SELECT column_name, data_type
FROM rw_catalog.rw_columns
WHERE relation_id = ('<schema>.<mv_name>')::regclass
  AND data_type ILIKE '%interval%';

Type guard

fn is_bigquery_supported(dt: &DataType) -> bool {
    !matches!(dt, DataType::Interval)
}

Prevention

Store durations as numeric seconds/milliseconds instead of INTERVAL in sinked views.
Cast INTERVAL to VARCHAR only when the raw value is acceptable downstream.
Avoid timestamp subtraction in views feeding BigQuery sinks, or extract epochs immediately.

When it happens

Trigger: Sinking to BigQuery when the schema includes an INTERVAL column, e.g. from date/time arithmetic (`end_time - start_time`).

Common situations: Users computing durations with subtraction of timestamps or date arithmetic and trying to persist the resulting INTERVAL values in BigQuery.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

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