risingwavelabs/risingwave · error · ExprError

Unsupported cast: {0} to {1}

Error message

Unsupported cast: {0} to {1}

What it means

ExprError::UnsupportedCast is thrown by the cast expression builder when there is no registered cast implementation between the two given DataTypes. Normally the frontend should reject such casts during binding; this surfaces when frontend/backend cast tables disagree or SQL forces an illegal cast.

Source

Thrown at src/expr/core/src/error.rs:52

impl From<ContextUnavailable> for ExprError {
    fn from(e: ContextUnavailable) -> Self {
        ExprError::Context(e.0)
    }
}

/// The error type for expression operations.
#[derive(Error, ReportDebug)]
pub enum ExprError {
    /// A collection of multiple errors in batch evaluation.
    #[error("multiple errors:\n{1}")]
    Multiple(ArrayRef, MultiExprError),

    // Ideally "Unsupported" errors are caught by frontend. But when the match arms between
    // frontend and backend are inconsistent, we do not panic with `unreachable!`.
    #[error("Unsupported function: {0}")]
    UnsupportedFunction(String),

    #[error("Unsupported cast: {0} to {1}")]
    UnsupportedCast(DataType, DataType),

    #[error("Casting to {0} out of range")]
    CastOutOfRange(&'static str),

    #[error("Numeric out of range")]
    NumericOutOfRange,

    #[error("Numeric out of range: underflow")]
    NumericUnderflow,

    #[error("Numeric out of range: overflow")]
    NumericOverflow,

    #[error("Division by zero")]
    DivisionByZero,

    #[error("Parse error: {0}")]

View on GitHub (pinned to 6469eb736d)

Solutions

1. Adjust the SQL to cast via an intermediate type (e.g. ::varchar then target)
2. Upgrade all nodes to the same RisingWave version
3. Check the cast support matrix in RisingWave docs
4. Implement/enable the missing cast arm if you're extending the engine

Example fix

// before
SELECT ts_col::int FROM t; -- unsupported direct cast
// after
SELECT extract(epoch from ts_col)::int FROM t;

// check cast support before issuing the cast
// consult risingwave cast matrix; e.g. avoid direct struct->timestamp casts

match query_result {
    Err(e) if e.to_string().starts_with("Unsupported cast:") => {
        // rewrite with intermediate cast e.g. ::varchar
    }
    r => r,
}

When it happens

Trigger: Building a CastExpression whose from/to DataType pair has no entry in the backend's cast implementation table (e.g. struct -> timestamp).

Common situations: Version skew between frontend and compute nodes; SQL with implicit/explicit casts the backend has not implemented; custom types in extensions.

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

• Casting to {0} out of range
• Expr error: {0}
• multiple errors: {1}
• Parse error: {0}
• Expression error: {0}

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