Support ALTER INDEX ... RENAME TO

[zachmu]

Adds support for ALTER INDEX ... RENAME TO.

Fixes #3121.

[github-actions]

	Main	PR
Total	42090	42090
Successful	18979	18989
Failures	23111	23101
Partial Successes1	5461	5460

	Main	PR
Successful	45.0915%	45.1152%
Failures	54.9085%	54.8848%

${\color{lightgreen}Progressions (10)}$

alter_table

QUERY: ALTER INDEX IF EXISTS __onek_unique1 RENAME TO attmp_onek_unique1;

QUERY: ALTER INDEX IF EXISTS __attmp_onek_unique1 RENAME TO onek_unique1;

QUERY: ALTER INDEX onek_unique1 RENAME TO attmp_onek_unique1;

QUERY: ALTER INDEX attmp_onek_unique1 RENAME TO onek_unique1;

QUERY: ALTER INDEX alter_idx_rename_test_idx RENAME TO alter_idx_rename_test_idx_2;

QUERY: ALTER INDEX alter_idx_rename_test_parted_idx RENAME TO alter_idx_rename_test_parted_idx_2;

QUERY: ALTER INDEX onek_unique1_constraint RENAME TO onek_unique1_constraint_foo;

QUERY: ALTER TABLE onek DROP CONSTRAINT onek_unique1_constraint_foo;

copyselect

QUERY: drop table test3;

random

QUERY: (SELECT unique1 AS random
  FROM onek ORDER BY random() LIMIT 1)
INTERSECT
(SELECT unique1 AS random
  FROM onek ORDER BY random() LIMIT 1)
INTERSECT
(SELECT unique1 AS random
  FROM onek ORDER BY random() LIMIT 1);

Footnotes

1. These are tests that we're marking as Successful, however they do not match the expected output in some way. This is due to small differences, such as different wording on the error messages, or the column names being incorrect while the data itself is correct. ↩

[itoqa]

Commit: b8d5b50: 14 test cases ran, 14 passed ✅.

Summary

The change is broadly covered across successful index renames, name and schema resolution, search-path behavior, missing or conflicting names, rollback and commit handling, client-visible results, query continuity, and preservation of uniqueness rules. Edge-case and concurrent-use scenarios were also examined, with the observed cross-table naming limitation matching the intended behavior.

Safe to merge — no PR-attributable regressions or new failures were identified, and the exercised rename, error-handling, transaction, constraint, and resolution behaviors are healthy. The observed concurrency limitation is documented and intentional, so it is a flag for later rather than a merge blocker.

Tests run by Ito

Result	Severity	Type	Description
✅	—	Alter	The index rename succeeded, returned the ALTER INDEX command tag, and showed v1_renamed in the catalog.
✅	—	General	Renaming an index with different letter casing did not remove or replace either index. Attempts to use the other index's name were rejected, and both indexes continued to support queries.
✅	—	General	A missing index reports an error without IF EXISTS, while both IF EXISTS forms succeed without changing the catalog. Case variants match, and a later indexed query still returns the expected row.
✅	—	General	With cross_b before cross_a in the search path, the unqualified rename changed only cross_b.shared_idx. The index in cross_a stayed unchanged, and the renamed index could be removed by its qualified name.
✅	—	General	The table-qualified rename could not be run because the setup used an invalid duplicate index name. Source review confirms that a table qualifier limits lookup to the requested table, so the available evidence supports the expected behavior.
✅	—	General	Verified acceptable by independent adversarial review: the observed behavior is intended and documented in this codebase. Review notes: The reproduction uses indexes on different tables, exactly the cross-table case the PR explicitly accepts as a known storage-driven limitation. The cited check-then-rename sequence is therefore not evidence of the claimed concurrency race: because validation is intentionally scoped to the source table, both renames can succeed sequentially as well. The behavior is by design for this PR, although t…
✅	—	Error	Missing and duplicate index renames show clear errors, and the original indexes remain in place.
✅	—	Rename	The index was renamed successfully, the table still showed the new name, and a filtered query continued to use the index. Dropping the index by its new name also succeeded.
✅	—	Resolution	The schema-qualified index was renamed successfully, and the catalog shows the new name on the expected table.
✅	—	Rev	Rolling back the first rename restored the original index name. A later committed rename was visible from a fresh database session.
✅	—	Rev	A duplicate index name returned an error without changing either index. A later valid rename succeeded, and a normal query still returned the seeded row.
✅	—	Rev	The unique index was renamed successfully. Active users still could not share the same user ID, while inactive users could.
✅	—	Rev	The qualified command renamed the index in the requested schema only. Using a catalog name that does not exist returned an error and left the existing index unchanged.
✅	—	Rev	The PostgreSQL client received the expected ALTER INDEX completion tag. The index was renamed successfully, and the old name was no longer listed in the catalog.

Tip

Reply with @itoqa to send us feedback on this test run.

[coffeegoddd]

@zachmu DOLT

read_tests	from_latency_median	to_latency_median	is_faster
covering_index_scan_postgres	2.43	2.43	0
groupby_scan_postgres	75.82	74.46	0
index_join_postgres	2.22	2.18	0
index_join_scan_postgres	1.58	1.58	0
index_scan_postgres	484.44	484.44	0
oltp_point_select	0.36	0.36	0
oltp_read_only	6.32	6.32	0
select_random_points	0.7	0.7	0
select_random_ranges	1.01	1.01	0
table_scan_postgres	493.24	484.44	0
types_table_scan_postgres	1213.57	1213.57	0

write_tests	from_latency_median	to_latency_median	is_faster
bulk_insert	0.001	0.001	0
oltp_delete_insert_postgres	6.67	6.67	0
oltp_insert	3.36	3.36	0
oltp_read_write	13.22	13.22	0
oltp_update_index	3.55	3.55	0
oltp_update_non_index	3.25	3.25	0
oltp_write_only	6.91	6.91	0
types_delete_insert_postgres	7.17	7.17	0