Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Comments on Why would an unique index get moved to the primary key after the underlying column is dropped?
Parent
Why would an unique index get moved to the primary key after the underlying column is dropped?
So I had a table with a primary key and a bunch of different columns. Columns A, B, and C were all unsigned ints (like the primary key column) and each column had a unique constraint
I dropped the A, B, and C columns, and then I got a warning that there were now duplicate unique constraints. When I checked the table structure I saw that unique indexes had been moved to the primary key column.
My assumption was that dropping a column would also drop its index, why would the index be moved to the primary key?
Post
I can't say that I fully understood what you did, but I think I got the explanation:
- removed 1+ columns that were part of the index. The index will be updated to not include that column.
If columns are dropped from a table, the columns are also removed from any index of which they are apart. If all columns that make up an index are dropped, the index is dropped as well.
- all secondary indexes include the PK columns. Not really sure, but dropping all the non-PK columns from the indexes you can get to your strange situation when the indexes are basically the same as the PK.
1 comment thread