PG upgrade path: existing DBs that already ran original InitialPostgres need a forward genre migration

[mforce]

Known limitation recorded at merge of PR #173 (issue #169), from @codex P1 on head 044a612.

The genre schema (Genre + GameGenre/GenreMovie/GenreMusicAlbum + IX_Genres_OwnerId_Name) was folded into the FIRST
Postgres migration 20260528000000_InitialPostgres (owner decision: treat PG as never deployed — all existing deployments
are SQLite; no PG databases existed). This is correct for FRESH PG installs, but a PG database that already applied the
ORIGINAL InitialPostgres (pre-merge) would never re-run it and has no later genre migration, so it would keep the legacy
comma-separated genre columns and miss the relational schema → collection queries would fail post-upgrade.

Documented owner position at merge: no PG databases exist, so this path is not live. If a PG deployment is ever added
or discovered that pre-dates this change, add a forward migration to create the genre schema for the upgrade path.
Fast-follow / documented limitation; not a blocker.

[mforce]

Closing per owner decision (mforce 2026-08-26): treat every deployment as a first install; PG is always first-install post-change, no pre-existing PG databases exist, existing rows don't matter. Under that ground truth there is no pre-change PG install to upgrade, so no forward migration is ever needed. The @codex P1 is dismissed by owner. (Hypothetically, if a pre-existing PG DB were ever discovered, a forward migration would be needed — documented here solely as a note, not an open work item.)

[chatgpt-codex-connector]

No code changes are needed. The owner explicitly dismissed the migration concern based on the project’s deployment assumptions, so I did not create a commit or pull request.

Checks

• ✅ git status --short --branch — working tree is clean.
• ✅ git log -1 --oneline — current branch remains at ade99b0.

View task →