db:add-missing-indices proposes duplicate table_id index for tables_row_sleeves

Steps to reproduce

1. Install Tables 2.2.2 on Nextcloud 33 with PostgreSQL.

2. Inspect the indexes on oc_tables_row_sleeves:

   SELECT indexname, indexdef
   FROM pg_indexes
   WHERE tablename = 'oc_tables_row_sleeves'
   ORDER BY indexname;
   

3. Observe that an index on table_id already exists:

   tables_tables_row_sleeves_t_id
   CREATE INDEX tables_tables_row_sleeves_t_id
   ON public.oc_tables_row_sleeves USING btree (table_id)
   

4. Run:

   php occ db:add-missing-indices --dry-run
   

5. Observe that Nextcloud proposes another index on the same column:

   Adding additional tables_row_sleeves_t_id index to the
   oc_tables_row_sleeves table, this can take some time...
   
   CREATE INDEX tables_row_sleeves_t_id
   ON oc_tables_row_sleeves (table_id);
   

Expected behavior

db:add-missing-indices should not propose a second index when an equivalent index on tables_row_sleeves(table_id) already exists.

The Tables schema migration and AddMissingIndicesListener should use a consistent index name. Existing installations using the migration-defined name should be handled without creating a duplicate index.

Actual behavior

The original Tables migration creates tables_tables_row_sleeves_t_id, while the current AddMissingIndicesListener registers tables_row_sleeves_t_id.

Nextcloud checks the registered index by name, treats the migration-created index as missing, and proposes a second B-tree index on the same table_id column. Running the command without --dry-run would create both indexes instead of recognizing or replacing the existing one.

Tables app version

2.2.2

Browser

Not applicable (server-side OCC/schema issue)

Client operating system

Not applicable

Operating system

Alpine Linux 3.24.1 container on Kubernetes

Web server

Nginx

PHP engine version

PHP 8.3

Database

PostgreSQL

Additional info

Nextcloud version: 33.0.8 Enterprise
PHP-FPM: 8.3.33
Nginx: 1.31.3
PostgreSQL: 18.4

Relevant source locations:

• The migration creates tables_tables_row_sleeves_t_id:
  https://github.com/nextcloud/tables/blob/v2.2.2/lib/Migration/Version000700Date20230916000000.php#L81-L96
• The listener requests tables_row_sleeves_t_id:
  https://github.com/nextcloud/tables/blob/v2.2.2/lib/Listener/AddMissingIndicesListener.php#L15-L23
• Nextcloud checks the registered index by name:
  https://github.com/nextcloud/server/blob/v33.0.8/core/Command/Db/AddMissingIndices.php#L50-L73

The mismatch is also present on the current Tables main branch.

The existing index is functional and actively used by PostgreSQL for queries filtering on table_id, so this is not a missing-index performance problem. The issue is that the maintenance command proposes a redundant index and leaves the database warning active.

A fix should account for installations where only the migration-defined name exists, only the listener-defined name exists, or both names exist because the maintenance command was already executed.

Start with lib/Migration/Version000700Date20230916000000.php and lib/Listener/AddMissingIndicesListener.php, then read Nextcloud's core/Command/Db/AddMissingIndices.php behavior. Reproduce the dry-run against the reported PostgreSQL schema and verify handling when either index name, or both names, exist. Done means no redundant index is proposed while the existing table_id index remains functional.