prestodb/presto · error · SemanticException

NOT_SUPPORTED

NOT_SUPPORTED

Error message

'%s' is a materialized view, not a table. Use DROP MATERIALIZED VIEW to drop.

What it means

Thrown by DropTableTask when DROP TABLE targets a name that is actually a materialized view. Presto distinguishes materialized views from tables, so dropping requires the DROP MATERIALIZED VIEW statement; a plain DROP TABLE is rejected as NOT_SUPPORTED unless IF EXISTS was specified (in which case it silently succeeds).

Source

Thrown at presto-main-base/src/main/java/com/facebook/presto/execution/DropTableTask.java:74

            throw new SemanticException(MISSING_CATALOG, "Catalog '%s' does not exist", tableName.getCatalogName());
        }

        if (!metadataResolver.schemaExists(tableName.getCatalogSchemaName())) {
            throw new SemanticException(MISSING_SCHEMA, statement, "Schema '%s' does not exist", tableName.getSchemaName());
        }

        Optional<TableHandle> tableHandle = metadataResolver.getTableHandle(tableName);
        if (!tableHandle.isPresent()) {
            if (!statement.isExists()) {
                throw new SemanticException(MISSING_TABLE, statement, "Table '%s' does not exist", tableName);
            }
            return immediateFuture(null);
        }

        Optional<MaterializedViewDefinition> optionalMaterializedView = metadataResolver.getMaterializedView(tableName);
        if (optionalMaterializedView.isPresent()) {
            if (!statement.isExists()) {
                throw new SemanticException(NOT_SUPPORTED, statement, "'%s' is a materialized view, not a table. Use DROP MATERIALIZED VIEW to drop.", tableName);
            }
            return immediateFuture(null);
        }

        accessControl.checkCanDropTable(session.getRequiredTransactionId(), session.getIdentity(), session.getAccessControlContext(), tableName);

        metadata.dropTable(session, tableHandle.get());

        return immediateFuture(null);
    }
}

View on GitHub (pinned to 55bb57d202)

Solutions

Rewrite the statement as DROP MATERIALIZED VIEW <name>
If the drop is best-effort cleanup, add IF EXISTS to DROP TABLE so it no-ops instead of failing
Query system.metadata or SHOW CREATE to confirm the object type before dropping

Example fix

// before
DROP TABLE sales_daily;
// after
DROP MATERIALIZED VIEW sales_daily;

Defensive patterns

Strategy: validation

Validate before calling

-- determine object type before dropping
SELECT table_type FROM system.metadata.tables
WHERE schema_name = 'my_schema' AND table_name = 'sales_daily';

Prevention

Check SHOW CREATE <name> to confirm the object type before DROP
Use DROP TABLE IF EXISTS only when the target is known to be a table
Generate drop scripts from metadata queries filtered on table_type

When it happens

Trigger: Executing `DROP TABLE mv_name` where mv_name resolves via metadataResolver.getMaterializedView(tableName) to an existing materialized view and the statement has no IF EXISTS clause.

Common situations: Developer created a table earlier, later replaced it with a materialized view of the same name, then runs an old DROP TABLE script; schema-automation tools emitting DROP TABLE generically without checking object type.

Understand the failure class

Background: Presto NOT_SUPPORTED error: what "not supported" means and how to fix it — this error's family across 3 libraries.

Related errors

AI-assisted analysis of prestodb/presto@55bb57d202 (2026-09-04). Data as JSON: /api/errors/e531dc5b94e6b512. Report an issue: GitHub.