What causes "precision must be in range {0}" in risingwavelabs/risingwave?

Lower the precision to within the supported range (e.g. DECIMAL precision must be <= 38 in RisingWave).

risingwavelabs/risingwave · error · OutOfRange

precision must be in range

Error message

precision must be in range {0}

What it means

Produced by the `precision_in_range` helper when a numeric literal inside parentheses after a type name falls outside the allowed range, e.g. `DECIMAL(100)` or `TIME(20)`. The helper wraps `literal_u64` with a range check and converts out-of-range values into this `OutOfRange` error, which is then surfaced to `non_keyword_datatype`.

Solutions

Lower the precision to within the supported range (e.g. DECIMAL precision must be <= 38 in RisingWave).
Check the allowed bounds in the error's range debug output and adjust your schema.
If you maintain the parser, ensure the range passed by `non_keyword_datatype` matches the documented limits and the message includes the concrete bounds.

Example fix

// before
CREATE TABLE t (x DECIMAL(45));
// after
CREATE TABLE t (x DECIMAL(38));

Defensive patterns

Strategy: validation

Validate before calling

fn check_decimal_precision(p: u64) -> Result<(), String> {
    if (1..=38).contains(&p) { Ok(()) } else { Err(format!("precision {p} out of 1..=38")) }
}

Try / catch

// Parse errors surface as ModalResult; match the OutOfRange message
match data_type_result {
    Err(e) if e.to_string().starts_with("precision must be in range") => {
        // clamp/fix precision and re-parse
    }
    other => other,
}

Prevention

Clamp declared precisions to the target engine's documented limits when porting DDL.
Validate generated schema DDL against engine limits before applying.
Keep a mapping table for cross-engine type/precision translation (Oracle NUMBER -> DECIMAL(38)).

When it happens

Trigger: Parsing type declarations like `DECIMAL(p)`, `TIME(p)`, `TIMESTAMP(p)`, `VARCHAR(p)` where `p` (or precision/scale pair) exceeds the range bound passed by the caller, e.g. `DECIMAL(45)` when max is 38.

Common situations: Porting DDL from other engines with larger precision limits (Oracle NUMBER, MySQL DECIMAL(65)); typo'd precision like an extra digit; generated schemas with invalid defaults.

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/cf69f57be5abc66c. Report an issue: GitHub.

Appendix: source

Thrown at src/sqlparser/src/parser_v2/number.rs:82

    S: TokenStream,
{
    token_number
        .try_map(|s| s.parse::<i64>())
        .context(StrContext::Label("i64"))
        .parse_next(input)
}

/// Consume a precision definition in some types, e.g. `FLOAT(32)`.
///
/// The precision must be in the given range.
pub fn precision_in_range<S>(
    range: impl RangeBounds<u64> + std::fmt::Debug,
) -> impl ModalParser<S, u64, ContextError>
where
    S: TokenStream,
{
    #[derive(Debug, thiserror::Error)]
    #[error("precision must be in range {0}")]
    struct OutOfRange(String);

    delimited(
        Token::LParen,
        cut_err(literal_u64.try_map(move |v| {
            if range.contains(&v) {
                Ok(v)
            } else {
                Err(OutOfRange(format!("{:?}", range)))
            }
        })),
        cut_err(Token::RParen),
    )
}

View on GitHub (pinned to 6469eb736d)