Repository: edgedb/edgedb

Issue:
`id` has two indexes on it
When we do `CREATE TYPE X`, the output will include:
```
    ALTER TABLE edgedbpub."cd004d40-1e17-11ef-8a08-8b5c1fe7f2d6" ADD COLUMN id uuid NOT NULL DEFAULT (edgedb.uuid_generate_v1mc()), ADD PRIMARY KEY (id);
    
    COMMENT ON COLUMN edgedbpub."cd004d40-1e17-11ef-8a08-8b5c1fe7f2d6".id IS '__::id';
    
    ALTER TABLE edgedbpub."cd004d40-1e17-11ef-8a08-8b5c1fe7f2d6" ALTER COLUMN id SET NOT NULL;
    
    ALTER TABLE edgedbpub."cd004d40-1e17-11ef-8a08-8b5c1fe7f2d6" ADD CONSTRAINT "cd01b53d-1e17-11ef-b688-f7f57c92bcad;schemaconstr" UNIQUE (id);
```

Which creates a constraint `id` in addition to it being a PRIMARY KEY.

This can be checked by querying `pg_indexes`.
```
_localdev:main> \psql
psql (16.2)
Type "help" for help.

V2f204ab5b0_main=# select indexname, tablename, indexdef from pg_indexes
where tablename = 'cd004d40-1e17-11ef-8a08-8b5c1fe7f2d6';
                     indexname                     |              tablename               |                                                                   indexdef                                                                   
---------------------------------------------------+--------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------
 cd004d40-1e17-11ef-8a08-8b5c1fe7f2d6_pkey         | cd004d40-1e17-11ef-8a08-8b5c1fe7f2d6 | CREATE UNIQUE INDEX "cd004d40-1e17-11ef-8a08-8b5c1fe7f2d6_pkey" ON edgedbpub."cd004d40-1e17-11ef-8a08-8b5c1fe7f2d6" USING btree (id)
 cd01b53d-1e17-11ef-b688-f7f57c92bcad;schemaconstr | cd004d40-1e17-11ef-8a08-8b5c1fe7f2d6 | CREATE UNIQUE INDEX "cd01b53d-1e17-11ef-b688-f7f57c92bcad;schemaconstr" ON edgedbpub."cd004d40-1e17-11ef-8a08-8b5c1fe7f2d6" USING btree (id)
(2 rows)
```

@elprans says there used to be something that prevented the constraint from being created; probably I removed or broke it at some point. We could restore that, or we could stop making it a PRIMARY KEY. Not sure if there is any real downside to the latter.


Discussion:
I think the best approach here is to just stop marking `id` as PRIMARY KEY.
@elprans Can you think of any downsides to that?
> @elprans Can you think of any downsides to that?

External SQL tools might expect there to be a primary key, at least for some modes of sync, but I'm not sure.

Resolving patch:
diff --git a/edb/pgsql/delta.py b/edb/pgsql/delta.py
--- a/edb/pgsql/delta.py
+++ b/edb/pgsql/delta.py
@@ -5811,15 +5811,6 @@ def _create_property(
                         cmd = dbops.AlterTableAddColumn(col)
                         alter_table.add_operation(cmd)
 
-                        if col.name == 'id':
-                            constraint = dbops.PrimaryKey(
-                                table_name=alter_table.name,
-                                columns=[col.name],
-                            )
-                            alter_table.add_operation(
-                                dbops.AlterTableAddConstraint(constraint),
-                            )
-
                     self.pgops.add(alter_table)
 
                 self.schedule_inhview_source_update(


Test patch:
diff --git a/tests/test_edgeql_ddl.py b/tests/test_edgeql_ddl.py
--- a/tests/test_edgeql_ddl.py
+++ b/tests/test_edgeql_ddl.py
@@ -16916,9 +16916,6 @@ async def test_edgeql_ddl_deadlock_02(self):
         self.assertEqual(cnt, 1)
         self.assertEqual(len(objs), 1)
 
-    @test.xfail('''
-        Issue #7413: We create two indexes on `.id`
-    ''')
     async def test_edgeql_ddl_single_index(self):
         # Test that types only have a single index for id
         await self.con.execute('''