@Rocky After performing

ALTER TABLE table1 SWAP WITH table2

, grants that were on table1 ended up on table2 instead. Is this intended behaviour. Shouldn't the grants remain tied to the table name and not change?

This is the intended behavior in StarRocks. In StarRocks, privileges for native tables are tied to the internal Table ID, not the table name. Why this happens When you perform an

ALTER TABLE table1 SWAP WITH table2

, StarRocks atomically swaps the metadata (including the data and the internal ID) associated with those two names. Since the grants are linked to the unique ID of the object: * The grants that were on the "old"

table1

(ID: A) stay with ID: A, which is now named

table2

. * The grants that were on the "old"

table2

(ID: B) stay with ID: B, which is now named

table1

. Why it works this way This design is primarily for security and consistency: 1. Security: If privileges were tied strictly to names, someone could drop a table they don't have access to, recreate a new one with the same name, and potentially "inherit" permissions they shouldn't have, or vice versa. 2. Renaming: It ensures that if you rename a table (e.g.,

ALTER TABLE old_name RENAME new_name

), you don't lose all your configured access control settings. Comparison with other operations * RENAME/SWAP: Privileges follow the table (ID) to its new name. * DROP and CREATE: If you

DROP

a table and create a new one with the same name, the privileges are lost because the new table receives a new internal ID. * External Tables: For some external catalog tables where StarRocks does not manage the metadata ID, behavior may differ in future versions, but for internal OLAP tables, the ID-based logic is standard. If your workflow requires the grants to stay with the name

table1

regardless of the underlying data swap, you would need to manually

REVOKE

and

GRANT

the permissions as part of your swap process, or grant permissions at the database level (

GRANT ... ON ALL TABLES IN DATABASE

) so they apply to any table name within that schema. References • sql-reference/sql-statements/table_bucket_part_index/ALTER_TABLE.md • knowledge/usage/best-practice.md • administration/user_privs/authorization/privilege_item.md • faq/Others.md • sql-reference/sql-statements/account-management/GRANT.md