prestodb/presto · error · PrestoException

SYNTAX_ERROR

SYNTAX_ERROR

Error message

Cannot rename tables across catalogs

What it means

MetadataManager.renameTable rejects RENAME attempts where the destination qualified name belongs to a different catalog than the table's current connector. Presto cannot move a table between connectors, so cross-catalog renames throw SYNTAX_ERROR. Renames must stay within the same catalog (and hence the same connector).

Source

Thrown at presto-main-base/src/main/java/com/facebook/presto/metadata/MetadataManager.java:789

    {
        ConnectorId partitioningConnectorId = partitioningMetadata.getPartitioningHandle().getConnectorId()
                .orElseThrow(() -> new IllegalArgumentException("connectorId is expected to be present in the connector partitioning handle"));
        checkArgument(
                connectorId.equals(partitioningConnectorId),
                "Unexpected partitioning handle connector: %s. Expected: %s.",
                partitioningConnectorId,
                connectorId);
        return new ConnectorPartitioningMetadata(partitioningMetadata.getPartitioningHandle().getConnectorHandle(), partitioningMetadata.getPartitionColumns());
    }

    @Override
    public void renameTable(Session session, TableHandle tableHandle, QualifiedObjectName newTableName)
    {
        String catalogName = newTableName.getCatalogName();
        CatalogMetadata catalogMetadata = getCatalogMetadataForWrite(session, catalogName);
        ConnectorId connectorId = catalogMetadata.getConnectorId();
        if (!tableHandle.getConnectorId().equals(connectorId)) {
            throw new PrestoException(SYNTAX_ERROR, "Cannot rename tables across catalogs");
        }

        ConnectorMetadata metadata = catalogMetadata.getMetadata();

        metadata.renameTable(session.toConnectorSession(connectorId), tableHandle.getConnectorHandle(),
                toSchemaTableName(newTableName.getSchemaName(), newTableName.getObjectName()));
    }

    @Override
    public void setTableProperties(Session session, TableHandle tableHandle, Map<String, Object> properties)
    {
        ConnectorId connectorId = tableHandle.getConnectorId();
        ConnectorMetadata metadata = getMetadataForWrite(session, connectorId);
        metadata.setTableProperties(session.toConnectorSession(connectorId), tableHandle.getConnectorHandle(), properties);
    }

    @Override
    public void renameColumn(Session session, TableHandle tableHandle, ColumnHandle source, String target)

View on GitHub (pinned to 55bb57d202)

Solutions

1. Rename within the same catalog only: ALTER TABLE cat.db.old RENAME TO cat.db.new
2. To move data across catalogs, CREATE TABLE new_cat.db.new AS SELECT * FROM old_cat.db.old, then drop the source
3. Use a connector-specific export/import or storage-level copy for large cross-catalog moves
4. Update scripts to resolve the target catalog from the source table's catalog

Example fix

// before
ALTER TABLE hive.default.events RENAME TO iceberg.default.events; -- cross-catalog
// after
CREATE TABLE iceberg.default.events AS SELECT * FROM hive.default.events;
DROP TABLE hive.default.events;

if (!newTableName.getCatalogName().equals(tableHandle.getConnectorId().getCatalogName())) {
    throw new IllegalArgumentException("Rename target must stay in catalog " + tableHandle.getConnectorId());
}

boolean sameCatalog(TableHandle h, QualifiedObjectName target) { return target.getCatalogName().equals(h.getConnectorId().getCatalogName()); }

try { metadataManager.renameTable(session, handle, newName); }
catch (PrestoException e) { if (SYNTAX_ERROR.getCode() == e.getErrorCode()) { /* fall back to CTAS + drop for cross-catalog moves */ } else throw e; }

When it happens

Trigger: Running ALTER TABLE ... RENAME TO <catalog>.<other>.<name> (or calling renameTable) where newTableName.getCatalogName() differs from tableHandle.getConnectorId()'s catalog.

Common situations: Users attempting to 'move' a table from one catalog to another via rename; scripts that build fully-qualified target names dynamically; confusion between schemas (allowed) and catalogs (not allowed) during renames.

Related errors

• MISSING_CATALOG
• INVALID_TABLE_PROPERTY
• Invalid time from server:
• Expected column to be a time type but is
• Invalid timestamp from server:

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