risingwavelabs/risingwave · error · ExprError

Unsupported function

Error message

Unsupported function: {0}

What it means

ExprError::UnsupportedFunction is raised by the backend when asked to evaluate a function it has no implementation for. The comment in the source notes this normally indicates a frontend/backend match-arm mismatch — the frontend allowed a function the backend cannot build.

Solutions

  1. Ensure all RisingWave nodes run the same version
  2. Verify the function is implemented/supported for this context (e.g. batch vs stream)
  3. Re-check UDF registration if the function is user-defined
  4. Report a bug if frontend and backend versions match — it's an inconsistency

Example fix

// before (frontend allows, backend lacks arm)
match expr.get_function_type() { ... } // unreachable arm -> UnsupportedFunction
// after
// add the missing match arm in the backend builder or restrict in frontend binder
Defensive patterns

Strategy: try-catch

Validate before calling

// check function support before issuing query
// e.g. verify function name appears in backend-supported list for your version

Try / catch

match result {
    Err(e) if e.to_string().starts_with("Unsupported function:") => {
        // rewrite query or upgrade cluster
    }
    r => r,
}

Prevention

When it happens

Trigger: A table function or expression node reaches backend ExpressionBuilder and its function kind falls into the catch-all arm; frontend and backend versions disagree on supported function sets.

Common situations: Rolling upgrades with version skew between frontend and compute nodes; newly added function queried while some nodes are stale; UDF registration missing on the compute node.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors


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

Appendix: source

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

    }
}

impl From<ContextUnavailable> for ExprError {
    fn from(e: ContextUnavailable) -> Self {
        ExprError::Context(e.0)
    }
}

/// 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")]

View on GitHub (pinned to 6469eb736d)