v5.6.0

Migrations keep the indexes and constraints a column change used to drop or rebuild: Changed answers in 5.6.0.

Changed answers

• Migrations: on PostgreSQL, changing a generated column's expression, its storage or a tsvector column's configuration drops the complex indexes, exclusion constraints, temporal constraints and temporal foreign keys on the column before the change and adds them after it. The migration dropped them with the column and never added them back (#184, Upgrading).
• Migrations: moving a table into the default schema keeps the complex indexes and constraints on it. They were dropped and created again, and on PostgreSQL, where Npgsql leaves such a table in its schema, the migration failed (42P01) (#185, Upgrading).
• Migrations: on SQL Server, changing only a column's default value, default SQL or comment keeps the complex indexes on it. Each was dropped and created again around the change, which issues no ALTER COLUMN (#186, Upgrading).
• Migrations: renaming a column keeps the complex indexes, exclusion constraints and temporal constraints that read it, and renames a default name that includes the column. They were dropped and created again around the rename. SQL Server still re-creates an index whose filter reads the column (#182, Upgrading).

Fixed

• Constraints: on PostgreSQL, a temporal foreign key whose name changes in the same migration as a key column type change or a rebuild of its principal constraint applies. A renamed principal table changes a default name. It failed at apply with 42804 or 2BP01 (#196, Temporal constraints).
• Constraints: on PostgreSQL, a temporal foreign key to a generic entity type such as Room<int> diffs from its migration snapshot, where every migrations add after the first, and Migrate(), failed because the principal could not be resolved (#197, Temporal foreign keys).
• Constraints: on PostgreSQL, a migration that drops a temporal foreign key's dependent table and drops or changes the principal's temporal constraint applies, where it failed at apply with 2BP01 (#187, Temporal constraints).
• Constraints: on PostgreSQL, changing a temporal foreign key's key column type on both tables applies, where it failed at apply with 42804 when EF Core altered the dependent table first (#188, Temporal constraints).
• Indexes: on SQL Server, a complex index whose filter or INCLUDE entry names a column in another case, [note] for Note, is dropped before an ALTER COLUMN or rename of that column and created after it, where the migration failed at apply, since SQL Server rejects either while the index exists (Msg 5074 for ALTER COLUMN) (#189).

Published to nuget.org through Trusted Publishing by this run. The CycloneDX SBOM for each package is attached below.