fix(se): render constraint renames as separate sql statements

[eruditmorina]

When applying/generating migrations, renaming primary key constraints in SQL (Postgres) requires statements to be separate from other table alter statements.

If we have multiple changes in the same table, the rename should be rendered as a separate sql statement otherwise it will throw a database error (picture below):

In this PR, I excluded the RenamePrimaryKey from alter table lines and am appending it to after_statements to be executed as a separate ALTER TABLE statement, that way the corresponding sql statements would render correctly.

Related issue:

• Primary key constraint renames yield invalid SQL prisma#18274

[janpio]

Neat.

Could you add a test that shows this working now (and failing before your change)?

Problem with prisma/prisma#18274 was that it does not have concrete steps for us to reproduce the problem - from your decsription above I assume this only applies for migration where a primary key is renamed while other things happen in the table?

[codspeed-hq]

CodSpeed Performance Report

Merging #4906 will not alter performance

_{Comparing eruditmorina:eruditmorina/schema-engine/fix-invalid-rename-primary-key-constraint (dbc585b) with main (9ee8c02)}

Summary

✅ 11 untouched benchmarks

[CLAassistant]

All committers have signed the CLA.

[eruditmorina]

@janpio as instructed, I added tests that show the correct rendering of the migration.

And I can confirm that as you put it, the problem applies for migrations where primary key is renamed, together with other changes in the same table, as part of the same migration.