What causes "Parse error: {0}" in risingwavelabs/risingwave?

Validate/cleanse the input before it reaches the cast, or use a fallible cast pattern that returns NULL on bad input.

risingwavelabs/risingwave · error · ExprError

Parse error: {0}

Error message

Parse error: {0}

What it means

ExprError::Parse(Box<str>) is thrown when parsing textual input into a typed value or expression fails. The Box<str> carries the free-form parse failure message. The source notes a TODO that string-based parsing errors should be replaced with structured error types, so the payload is unstructured and best used for display, not programmatic matching.

Source

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

    #[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(
        #[from]
        #[backtrace]
        ArrayError,
    ),

    #[error("More than one row returned by {0} used as an expression")]

View on GitHub (pinned to 6469eb736d)

Solutions

Validate/cleanse the input before it reaches the cast, or use a fallible cast pattern that returns NULL on bad input.
Fix the offending literal/data value indicated in the parse message.
Pre-cast at ingestion time with explicit handling of invalid rows (reject or default them).

Example fix

// before
SELECT '12x3'::int;
// after
SELECT CASE WHEN '12x3' ~ '^[0-9]+$' THEN '12x3'::int ELSE NULL END;

Defensive patterns

Strategy: validation

Validate before calling

-- pre-validate before cast
SELECT CASE WHEN val ~ '^[0-9]+$' THEN val::int ELSE NULL END FROM t;

Try / catch

// Treat as data-quality issue; catch and route to a dead-letter path
match eval_result {
    Err(e) if e.to_string().starts_with("Parse error") => quarantine(row, e),
    other => other?,
}

Prevention

Validate string formats at ingestion, before casts run in queries.
Prefer explicit, strict literals in SQL; avoid casting raw user text inline.
Keep date/numeric parsing in a single well-tested helper expression.

When it happens

Trigger: Casting/parsing a string to a typed value (e.g. `'abc'::int`, `to_timestamp`, decimal parsing) inside expression evaluation; any expression-function that parses text and maps its internal parse failure into ExprError.

Common situations: Dirty input data feeding a cast, locale/format mismatches in date or numeric literals, ingestion of malformed strings that are later cast in a materialized view, version changes tightening strictness of type parsing.

Understand the failure class

Background: "Invalid ... format", "must be in format X", "does not look like a ..." — invalid argument format errors across CLI tools and libraries — this error's family across 17 libraries.

Parsing and encoding errors: unexpected token, malformed input — why parsers reject input and how to find the real culprit.

Related errors

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