risingwavelabs/risingwave · error
RESET CONFIG is only supported for materialized views
Error message
RESET CONFIG is only supported for materialized views
What it means
ALTER VIEW ... RESET CONFIG resets streaming configuration keys back to defaults. The handler only supports this operation on materialized views; issuing it on a regular (non-materialized) view is rejected up front with this error because regular views have no streaming configuration to reset.
Solutions
- Target a materialized view instead: run `ALTER MATERIALIZED VIEW <name> RESET (...)` on the actual MV.
- If the object should be a materialized view, create one (`CREATE MATERIALIZED VIEW`) and reset its config there.
- Remove the RESET CONFIG statement for plain views, since they carry no streaming config.
Example fix
// before ALTER VIEW my_view RESET (parallelism); // after ALTER MATERIALIZED VIEW my_mv RESET (parallelism);
Defensive patterns
Strategy: validation
Validate before calling
-- Verify the target is a materialized view before issuing RESET CONFIG SELECT relation_kind FROM rw_catalog.rw_relations WHERE name = 'my_view'; -- proceed only if relation_kind = 'materialized-view'
Type guard
fn is_materialized_view(relation_kind: &str) -> bool {
relation_kind == "materialized-view"
} Try / catch
match session.alter_view_reset_config(name, keys).await {
Err(e) if e.message().contains("only supported for materialized views") => {
// surface: use ALTER MATERIALIZED VIEW instead
}
other => other?,
} Prevention
- Check rw_relations catalog for the relation kind before ALTER operations.
- Use ALTER MATERIALIZED VIEW syntax explicitly for MVs.
- Never apply config-reset statements to plain views.
When it happens
Trigger: Running `ALTER VIEW <name> RESET ( key1, ... )` where <name> resolves to a plain view rather than a materialized view, i.e. the `materialized` flag in the alter-view handler is false.
Common situations: Developers confusing plain views with materialized views in RisingWave; copying a config-reset statement written for an MV and applying it to a regular view; scripts that iterate over all relations in a schema and try to reset configs uniformly.
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
- ALTER TABLE ALTER WATERMARK is not supported for iceberg…
- ALTER TABLE is not supported for iceberg table without auto…
- ALTER TABLE is not supported for iceberg table: . …
- ALTER TABLE REFRESH SCHEMA is not supported for iceberg…
- ALTER TABLE RENAME is not supported for iceberg table
AI-assisted analysis of risingwavelabs/risingwave@6469eb736d (2026-09-11).
Data as JSON: /api/errors/36b043c157119495.
Report an issue: GitHub.
Appendix: source
Thrown at src/frontend/src/handler/mod.rs:1236
bail_not_implemented!("ALTER MATERIALIZED VIEW AS QUERY");
}
alter_mv::handle_alter_mv(handler_args, name, query).await
}
AlterViewOperation::SetConfig { entries } => {
if !materialized {
bail!("SET CONFIG is only supported for materialized views");
}
alter_streaming_config::handle_alter_streaming_set_config(
handler_args,
name,
entries,
statement_type,
)
.await
}
AlterViewOperation::ResetConfig { keys } => {
if !materialized {
bail!("RESET CONFIG is only supported for materialized views");
}
alter_streaming_config::handle_alter_streaming_reset_config(
handler_args,
name,
keys,
statement_type,
)
.await
}
}
}
Statement::AlterSink { name, operation } => match operation {
AlterSinkOperation::AlterConnectorProps {
alter_props: changed_props,
} => alter_sink_props::handle_alter_sink_props(handler_args, name, changed_props).await,
AlterSinkOperation::RenameSink { sink_name } => {
alter_rename::handle_rename_sink(handler_args, name, sink_name).awaitView on GitHub (pinned to 6469eb736d)