• You must own any table you rename.

• The name of the new table must conform to the naming rules for tables (see page Object Naming Rules).

• There must be no table already existing in the database having the same name and owned by the same user as the new table name. (The new table name will get the same internal relation ID (reltid) as the old table name.)

• You cannot rename a system catalog, extended system catalog, Replicator catalogs, or any tables owned by the super user $ingres.

• Renaming a table will put a checkpoint lock on the database to avoid online checkpoints while the ALTER TABLE or RENAME statement is executed. The statement will put an exclusive lock on the table being renamed.

• Indexes, grants, comments, synonyms, sequences, partitions, extension tables are automatically transferred to the newly renamed table or column.

• The ALTER TABLE or RENAME operation can be rolled back.

• If any procedures, views, rules, foreign key constraints or check constraints, integrities, non-grant permits, or security alarms refer to the table being renamed, the rename operation will fail with errors. Names of dependent objects are included in the error log for each dependent object.

• Primary key constraints and unique constraints on the table will be transferred to the new table name.

• Any forms, join definitions, or reports that refer to the old table name will be invalidated; these must be recreated and reloaded. Any copydb (unloaddb) scripts generated before renaming the table can no longer be used for reload operations.

• ALTER TABLE RENAME or RENAME TABLE statements are not supported in Ingres Star. For more information, see the Star User Guide.

• Procedures are not permitted to execute ALTER TABLE RENAME or RENAME TABLE statements.

• If a renamed table is registered with Ingres Replicator, the dd_regist_tables and dd_regist_columns catalogs must be updated for the replication to work. For more information, see the Replicator User Guide.