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
- Ensure all RisingWave nodes run the same version
- Verify the function is implemented/supported for this context (e.g. batch vs stream)
- Re-check UDF registration if the function is user-defined
- 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
- Keep all cluster nodes on the same version
- Verify function availability in the docs before using in production SQL
- Test new SQL against the target deployment version
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
- BatchPosixFsReader should not be used
- bounded compaction is not supported for copy-on-write tasks
- column " " cannot be altered; only types containing struct…
- file_scan function is not supported in streaming mode
- Iceberg metadata relations are not supported in streaming…
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)