risingwavelabs/risingwave · error · ErrorCode::NotSupported

Not supported: {0}\nHINT: {1}

Error message

Not supported: {0}\nHINT: {1}

What it means

`ErrorCode::NotSupported` reports a feature or SQL construct that RisingWave intentionally does not support. It is thrown only when the query is meant to be rejected, and the second `String` field is a HINT suggesting what to do instead.

Source

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

    #[error("internal error: {0}")]
    InternalError(String),
    // TODO: unify with the above
    #[error(transparent)]
    Uncategorized(
        #[from]
        #[backtrace]
        anyhow::Error,
    ),
    #[error("connector error: {0}")]
    ConnectorError(
        #[source]
        #[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]`

View on GitHub (pinned to 6469eb736d)

Solutions

1. Read the HINT portion of the message — it states the supported alternative
2. Rewrite the query per the hint (e.g. use a different clause or object type)
3. Check RisingWave docs/release notes for the feature's availability
4. If support is needed, upvote/open a feature request with the statement

Example fix

-- before
ALTER MATERIALIZED VIEW mv RENAME COLUMN a TO b;
-- after (per typical hint: recreate the MV)
CREATE MATERIALIZED VIEW mv2 AS SELECT a AS b, ... FROM ...;

// validate statement against supported feature matrix before submitting
// e.g. check docs: is ALTER MATERIALIZED VIEW ... RENAME supported?

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

match err.get_code() { ErrorCode::NotSupported(what, hint) => { apply_hint(hint); }, _ => propagate }

When it happens

Trigger: Frontend binder/planner explicitly rejects: e.g. unsupported DDL combinations, operations invalid for materialized views (certain UPDATE/DELETE targets, unsupported time travel), or features gated behind flags.

Common situations: Migrating SQL from Postgres that uses syntax RisingWave hasn't implemented, attempting mutations or session features not valid on streaming objects, or using a deprecated option.

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

• relative_error={} does not satisfy 0.0 < relative_error < 1.
• {} must contain 1 argument
• {object_type} not found: {name}
• Bind error: {0}
• should be set for vector index

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