pkgw
commented
6 years ago I think what's going on here is that "parts_paper_pkey" is the name of the index attached to this particular table. Indices are given names so that you can refer to them with certain specialized PSQL commands such as ALTER INDEX. (Sometimes you want to define more than one index over a single table.) But beyond that, the name of the index doesn't matter — its usefulness arises automatically from its definition as the index over the pair of keys (hpn, hpn_rev).
In this context, I wouldn't be surprised if Alembic isn't clever enough to rename indices, or just didn't bother to do so.
Overall, then, I believe this is something that you don't need to worry about. If at some point you add an Alembic migration command that directly affects this index, a manual fix might be necessary, but I think the odds of that happening are low. As such I'll go ahead and close this, but feel free to reopen if you think there's more to investigate.
A long while ago I used alembic to change a table name from "parts_paper" to "parts". I just noticed now that it finds as "Indexes" parts_paper_pkey for the primary key. I don't know if this matters or not (things seem be working), but is that a problem with how I did it, or alembic?
hera_mc=# \d parts Table "public.parts" Column | Type | Modifiers ---------------------+-----------------------+----------- hpn | character varying(64) | not null hpn_rev | character varying(32) | not null hptype | character varying(64) | not null manufacturer_number | character varying(64) | start_gpstime | bigint | not null stop_gpstime | bigint | Indexes: "parts_paper_pkey" PRIMARY KEY, btree (hpn, hpn_rev)