[CaffeinatedCoder]

Closes #184

Into release/5.x: SchemaKit's differ is new code. Closes acts only on main, so #184 is closed by hand after the merge.

Problem

On PostgreSQL, changing a generated column's expression, its storage or a tsvector column's configuration silently dropped every complex index, exclusion constraint, temporal constraint and temporal foreign key on the column. PostgreSQL cannot change a generation expression in place, so Npgsql renders the AlterColumnOperation as DROP COLUMN plus ADD COLUMN. It then re-creates only EF Core's own indexes (NpgsqlMigrationsSqlGenerator.Generate(AlterColumnOperation, …), Npgsql 10). The declarations were unchanged, so the differs emitted nothing. The migration ran without an error, the snapshot still listed everything, and the next migrations add was empty.

Change

• NpgsqlComplexIndexMigrationsModelDiffer: RecreatesColumn applies Npgsql's own condition: ComputedColumnSql or IsStored changed, plus the Npgsql:TsVectorConfig/TsVectorProperties annotations, which Npgsql turns into the expression before it compares. RequiresIndexRecreation treats such an operation on a column the index reads as in the way. That's the same path SQL Server: ALTER COLUMN on a column under a complex index fails at apply (Msg 5074) #84/SQL Server: a renamed complex index stays in the way of ALTER COLUMN, and the migration fails at apply (Msg 5074) #141 use on SQL Server: drop before the base operations, create after them.
• Exclusion and temporal diffs get the same check (RecreatedColumns, ReadsRecreatedColumn), covering columns and the columns named in expressions and filters.
  • An unchanged constraint in the way is dropped and added again.
  • A rename pair in the way stays a drop and an add.
  • A temporal FK goes with a rebuilt principal constraint through the existing rebuilt list. Without that, the principal's DROP COLUMN fails (2BP01).
  • A temporal FK whose own dependent column is recreated is rebuilt too.
• NpgsqlAnnotations mirrors the two tsvector keys, since Npgsql's NpgsqlAnnotationNames is internal API.
• CustomMigrationsModelDiffer.ColumnsNamedIn takes a table rather than an index descriptor and is internal, so the constraints read columns the same way indexes do.
• Docs: a ### Changed answers row (PostgreSQL: changing a generated column's expression silently drops every complex index and constraint on it #184 is silent), and docs/upgrading.md A changed generated column keeps what reads it, which says how to find and re-add what an earlier migration dropped. CLAUDE.md is updated too.

Tests

• GeneratedColumnRecreationTests, five tests, each asserting what is dropped before the AlterColumnOperation and created after it:
  • a changed expression rebuilds the two indexes that read the column (one only through its filter) and leaves the rest
  • a changed period rebuilds the exclusion and temporal constraints and the temporal FK, FK dropped first and added last
  • a changed dependent period rebuilds only the FK
  • a changed tsvector configuration rebuilds its GIN index
  • a column that becomes generated rebuilds what reads it
• PostgresIntegrationTests.Changed_generation_expression_keeps_indexes_and_constraints applies the change on PostgreSQL 18 with the target model, as database update does. It checks that EF Core's own index, the complex index, the exclusion constraint, the temporal constraint and the temporal FK all exist afterwards, and that the exclusion constraint still enforces (23P01). ApplyInTransaction gains an optional model, because Npgsql re-creates EF's own indexes only when it is given one.
• With the source fix reverted, all five unit tests and the integration test fail.
• Unit suite: 674 passed. PostgreSQL 18 and 16 integration suites: passed.

🤖 Generated with Claude Code