risingwavelabs/risingwave · error · ExprError

Casting to {0} out of range

Error message

Casting to {0} out of range

What it means

ExprError::CastOutOfRange signals that a value could not be cast into the target type because it exceeds the target's representable range (e.g. a large int64 cast to int16). It differs from NumericOutOfRange in that the failing type name is included in the message.

Source

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

    }
}

/// 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}")]
    // TODO(error-handling): should prefer use error types than strings.
    Parse(Box<str>),

View on GitHub (pinned to 6469eb736d)

Solutions

1. Use a wider target type for the cast
2. Use try_cast to get NULL instead of an error
3. Clamp or validate source values before casting
4. Clean out-of-range rows from the source data

Example fix

// before
SELECT col::smallint FROM t;
// after
SELECT try_cast(col as smallint) FROM t;

// pre-check range before casting (pseudo)
if v < i16::MIN as i64 || v > i16::MAX as i64 {
    // handle before casting to smallint
}

match eval_result {
    Err(e) if e.to_string().contains("out of range") => {
        // NULL-out or widen the target type
    }
    r => r,
}

When it happens

Trigger: Executing a cast expression (e.g. `::smallint`, decimal to float narrowing) where the source value exceeds the destination type's min/max during batch evaluation.

Common situations: Dirty data in a column; ETL migrations casting wide types to narrow ones; user SQL with explicit narrow casts over real data.

Understand the failure class

Background: "value must be between 0 and 1" / "out of range" / "must not be negative" errors: fixing range-validation failures across open-source libraries — this error's family across 42 libraries.

Related errors

• Unsupported cast: {0} to {1}
• 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/2ebd38080fce0a14. Report an issue: GitHub.