Comment 2 for bug 1103672

This is a new limitation, not a bug; here's why:

For the original bug 1062324, the columns in the new, re-created PK also exist in the original table, and there's a unique key on those cols in the new table, too. So this is like promoting a unique key to the PK, and the tool handles this.

This issue here is doing something fundamentally different: it's creating a new PK with a new column (_id). Furthermore, the original PK column (id) changes from unique to non-unique because no unique index is added to it in the new table.

So it's not the same bug; it's a question of whether or not we can and should handle this new issue. I'll have to think about how we might do this, i.e. if the magic is worth the effort given that there's a workaround.