risingwavelabs/risingwave · error · ErrorCode::ExprError

Expr error: {0}

Error message

Expr error: {0}

What it means

`ErrorCode::ExprError` wraps a type-erased `BoxedError` from the expression evaluation framework. It indicates an expression could not be built or evaluated — typically type/argument problems in scalar functions — with the underlying cause chained as `#[source]`.

Source

Thrown at src/frontend/src/error.rs:73

        #[backtrace]
        BoxedError,
    ),
    #[error(transparent)]
    NotImplemented(#[from] NotImplemented),
    // Tips: Use this only if it's intended to reject the query
    #[error("Not supported: {0}\nHINT: {1}")]
    NotSupported(String, String),
    #[error(transparent)]
    NoFunction(#[from] NoFunction),
    #[error(transparent)]
    IoError(#[from] std::io::Error),
    #[error("Storage error: {0}")]
    StorageError(
        #[backtrace]
        #[source]
        BoxedError,
    ),
    #[error("Expr error: {0}")]
    ExprError(
        #[source]
        #[backtrace]
        BoxedError,
    ),
    // TODO(error-handling): there's a limitation that `#[transparent]` can't be used with `#[backtrace]` if no `#[from]`
    // So we emulate a transparent error with "{0}" display here.
    #[error("{0}")]
    BatchError(
        #[source]
        #[backtrace]
        // `BatchError`
        BoxedError,
    ),
    #[error("Array error: {0}")]
    ArrayError(
        #[from]
        #[backtrace]

View on GitHub (pinned to 6469eb736d)

Solutions

  1. Read the chained source error for the exact expression failure
  2. Check operand types and add explicit casts (e.g. `::varchar`, `::int`)
  3. Verify the function exists and supports these argument types in this RisingWave version
  4. Simplify the expression to isolate the failing sub-expression

Example fix

-- before
SELECT my_udf(int_col) FROM t; -- ExprError: expects varchar
-- after
SELECT my_udf(int_col::varchar) FROM t;
Defensive patterns

Strategy: validation

Validate before calling

-- pre-check operand types
SELECT pg_typeof(int_col), pg_typeof('x') FROM t LIMIT 1;

Type guard

fn is_expr_error(e: &RwError) -> bool { matches!(e.get_code(), ErrorCode::ExprError(_)) }

Try / catch

match err.get_code() { ErrorCode::ExprError(inner) => log_expr_failure(inner), _ => propagate }

Prevention

When it happens

Trigger: Planning or executing expressions: a function called with unsupported argument types, constant-folding failure, or a projection/agg expression that fails signature resolution.

Common situations: Calling a UDF/builtin with wrong-typed columns, NULL-handling mismatches, using an expression in a context (index, filter on MV) where its type isn't supported.

Understand the failure class

Background: Type mismatch errors: IllegalArgumentException, TypeError and type guards across 150 open-source libraries — this error's family across 150 libraries.

Related errors


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