• You must own any table you rename.

• The name of the new table must conform to the naming rules for tables (see 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 are automatically transferred to the newly renamed table or column. For grants, the query text stored in the iiqrytext catalog is updated to reflect the new table name.

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

• If any views 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, foreign 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 or unloaddb scripts generated before renaming the table can no longer be used for reload operations.