risingwavelabs/risingwave · error · SinkError::BigQuery

INT256 is not supported for BigQuery sink.

Error message

INT256 is not supported for BigQuery sink.

What it means

RisingWave's Int256 (arbitrary-precision 256-bit integer) exceeds what BigQuery's INT64/NUMERIC mappings cover, so the connector rejects any sink schema containing an Int256 column rather than truncating silently.

Source

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

                let mut elements_vec = vec![];
                for (name, datatype) in structs.iter() {
                    let element_string =
                        Self::get_string_and_check_support_from_datatype(datatype)?;
                    elements_vec.push(format!("{} {}", name, element_string));
                }
                Ok(format!("STRUCT<{}>", elements_vec.join(", ")))
            }
            DataType::List(l) => {
                let element_string = Self::get_string_and_check_support_from_datatype(l.elem())?;
                Ok(format!("ARRAY<{}>", element_string))
            }
            DataType::Bytea => Ok("BYTES".to_owned()),
            DataType::Jsonb => Ok("JSON".to_owned()),
            DataType::Variant => Err(SinkError::BigQuery(anyhow::anyhow!(
                "VARIANT is not supported for BigQuery sink."
            ))),
            DataType::Serial => Ok("INT64".to_owned()),
            DataType::Int256 => Err(SinkError::BigQuery(anyhow::anyhow!(
                "INT256 is not supported for BigQuery sink."
            ))),
            DataType::Map(_) => Err(SinkError::BigQuery(anyhow::anyhow!(
                "MAP is not supported for BigQuery sink."
            ))),
            DataType::Vector(_) => Err(SinkError::BigQuery(anyhow::anyhow!(
                "VECTOR is not supported for BigQuery sink."
            ))),
        }
    }

    fn map_field(rw_field: &Field) -> Result<TableFieldSchema> {
        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 => {

View on GitHub (pinned to 6469eb736d)

Solutions

  1. Cast the INT256 column to DECIMAL/NUMERIC in the MV (may lose precision for very large values)
  2. Or cast to VARCHAR/STRING to preserve the full value, storing it as a BigQuery STRING
  3. Or cast to BIGINT (INT64) only if values are known to fit in 64 bits

Example fix

-- before
CREATE MATERIALIZED VIEW mv AS SELECT balance FROM eth_balances; -- INT256
-- after
CREATE MATERIALIZED VIEW mv AS SELECT CAST(balance AS VARCHAR) AS balance FROM eth_balances;
Defensive patterns

Strategy: validation

Validate before calling

SELECT column_name FROM information_schema.columns
WHERE table_name = 'mv' AND udt_name IN ('int256','uint256');
-- must return zero rows before CREATE SINK

Type guard

fn sink_ready(field: &Field) -> bool { !matches!(field.data_type(), DataType::Int256) }

Try / catch

match get_string_and_check_support_from_datatype(&dt) {
    Err(e) if e.to_string().contains("INT256 is not supported") => {
        eprintln!("cast INT256 to VARCHAR or DECIMAL in the MV");
    }
    _ => {}
}

Prevention

When it happens

Trigger: Creating a BigQuery sink on a relation with an INT256 column (typically from EVM/blockchain data ingestion); validation fails in `get_string_and_check_support_from_datatype` on DataType::Int256.

Common situations: Blockchain analytics pipelines where uint256 values (balances, token amounts) are INT256 in RW.

Related errors

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