risingwavelabs/risingwave · error · ExprError

Numeric out of range: overflow

Error message

Numeric out of range: overflow

What it means

ExprError::NumericOutOfRange variant: a numeric computation or conversion produced a value above the maximum representable for the target type during expression evaluation (e.g. integer arithmetic overflow, decimal conversion). It is a generic sentinel raised wherever expression evaluation detects positive out-of-range results.

Source

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

    // 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>),

    #[error("Invalid parameter {name}: {reason}")]
    // TODO(error-handling): should prefer use error types than strings.
    InvalidParam {
        name: &'static str,
        reason: Box<str>,
    },

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

View on GitHub (pinned to 6469eb736d)

Solutions

  1. Widen the result/intermediate type (e.g. decimal with more precision)
  2. Use checked/try variants (try_cast) to tolerate overflow
  3. Refactor arithmetic to reduce intermediate magnitude
  4. Validate input magnitudes before computation

Example fix

// before
SELECT col::int FROM t; -- exceeds i32 max
// after
SELECT try_cast(col as bigint) FROM t;
Defensive patterns

Strategy: validation

Validate before calling

// pre-check upper bound before narrowing
if v > max_allowed { /* clamp or NULL before cast */ }

Try / catch

match eval_result {
    Err(e) if e.to_string().contains("overflow") => {
        // widen type (e.g. bigint/decimal) and re-run
    }
    r => r,
}

Prevention

When it happens

Trigger: Evaluating arithmetic (e.g. large multiplication, exponent-like growth via repeated ops) or casts where the result exceeds the target type's upper bound during expression evaluation.

Common situations: Multiplying large integer columns; cumulative aggregations exceeding int64/decimal bounds; casting wide numerics into narrower types over real datasets.

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


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