What causes "Cannot rename a column in table %s%s" in prestodb/presto?

Grant ALTER/RENAME privilege or table ownership to the executing principal.

prestodb/presto · error · AccessDeniedException

Cannot rename a column in table %s%s

Error message

Cannot rename a column in table %s%s

What it means

Presto throws this AccessDeniedException (PERMISSION_DENIED / ACCESS_DENIED) when the identity is not authorized to rename a column. The connector's AccessControl.checkCanRenameColumn implementation denied ALTER TABLE ... RENAME COLUMN via denyRenameColumn. This is an intentional authorization denial for DDL that changes table schema.

Source

Thrown at presto-spi/src/main/java/com/facebook/presto/spi/security/AccessDeniedException.java:207

    public static void denyAlterColumn(String tableName)
    {
        denyAlterColumn(tableName, null);
    }

    public static void denyAlterColumn(String tableName, String extraInfo)
    {
        throw new AccessDeniedException(format("Cannot alter a column for table %s%s", tableName, formatExtraInfo(extraInfo)));
    }

    public static void denyRenameColumn(String tableName)
    {
        denyRenameColumn(tableName, null);
    }

    public static void denyRenameColumn(String tableName, String extraInfo)
    {
        throw new AccessDeniedException(format("Cannot rename a column in table %s%s", tableName, formatExtraInfo(extraInfo)));
    }

    public static void denySelectTable(String tableName)
    {
        denySelectTable(tableName, null);
    }

    public static void denySelectTable(String tableName, String extraInfo)
    {
        throw new AccessDeniedException(format("Cannot select from table %s%s", tableName, formatExtraInfo(extraInfo)));
    }

    public static void denyInsertTable(String tableName)
    {
        denyInsertTable(tableName, null);
    }

    public static void denyInsertTable(String tableName, String extraInfo)

View on GitHub (pinned to 55bb57d202)

Solutions

Grant ALTER/RENAME privilege or table ownership to the executing principal.
Run the rename as an owner/admin account.
Update migration tooling credentials to use a privileged service account.
Connector authors: implement checkCanRenameColumn to allow legitimate owners instead of always calling denyRenameColumn.

Example fix

// before
ALTER TABLE reports.t RENAME COLUMN nm TO name; -- Access Denied

// after
-- executed as table owner
ALTER TABLE reports.t RENAME COLUMN nm TO name; -- OK

Defensive patterns

Strategy: validation

Validate before calling

boolean canRenameColumn = grantsContain(showGrants(table), currentUser, "ALTER");
if (!canRenameColumn) {
    throw new IllegalStateException("Principal lacks ALTER (rename column) on " + table);
}

Prevention

Run refactoring migrations as the table owner.
Avoid interactive renames by non-owner users; route through reviewed migrations.
Verify the correct catalog/schema so grants line up.
Document which roles hold ALTER privileges per table.

When it happens

Trigger: Executing ALTER TABLE t RENAME COLUMN old TO new where the connector's checkCanRenameColumn(Identity, SchemaTableName) denies the current user.

Common situations: Users renaming columns in Hive/Iceberg tables without ownership; deployment pipelines performing schema refactors with restricted credentials; connectors denying DDL entirely.

Related errors

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