[CaffeinatedCoder]

Closes #185

Into release/5.x. Closes acts only on main, so #185 is closed by hand after the merge.

Problem

Moving a table into the default schema (ToTable("bookings", "north") → ToTable("bookings")) dropped and re-created every complex index, exclusion constraint, temporal constraint and temporal foreign key on it. EF Core writes the target's schema into RenameTableOperation.NewSchema, so null means the default schema (MigrationsModelDiffer: NewSchema = target.Schema). The differs read null as "unchanged" (NewSchema ?? Schema), compared the source under its old schema, and matched nothing.

• SQL Server: each index was rebuilt, although ALTER SCHEMA … TRANSFER keeps them.
• PostgreSQL: the migration failed with 42P01. Npgsql 10 renders nothing for a move whose NewSchema is null (Generate(RenameTableOperation, …) checks NewSchema is not null), so the table stays in its schema. The creates then named a table in the default schema that doesn't exist.

Change

NewSchema is now read as EF Core writes it in the three places that build renamed-table identities: CustomMigrationsModelDiffer.GetDifferences, SourceColumnRenames (so #182's column-rename fix covers such a table too), and the Npgsql differ's BuildRenamedTables. The SQLite rebuild path already read it that way.

PostgreSQL stays on Npgsql's behaviour. The migration now runs, and the table stays in its old schema, as it does without this package. docs/upgrading.md says to name the schema (ToTable("bookings", "public")) to actually move it. Reporting that no-op to npgsql/efcore.pg is your call.

Also: a ### Changed answers row in all four changelogs, a docs/upgrading.md entry, CLAUDE.md, and ToTable added to DocumentationApiTests.ExternalApi.

Tests

• SchemaMoveTests:
  • On PostgreSQL, moving into the default schema gives only the RenameTableOperation. The model has an exclusion constraint, a temporal constraint, and a temporal FK whose principal moves.
  • The same move plus a column rename gives only the rename operations.
  • Moves between named schemas, and out of the default schema, are unchanged.
  • The same check on SQL Server.
• PostgresIntegrationTests.Move_into_default_schema_applies (PostgreSQL 18): the migration runs, and the index and exclusion constraint keep their OIDs.
• SqlServerIntegrationTests.Move_into_default_schema_keeps_the_indexes (CI only): no index operations, and the index exists after the transfer.
• With the source fix reverted: the three move-into-default unit tests and the PostgreSQL integration test fail (42P01: relation "sm_bookings" does not exist). The two moves that already worked pass either way, on purpose.
• Suites: unit plus PostgreSQL 18/16, 716 passed.

🤖 Generated with Claude Code