Scheduling SQL with pg_cron, guarded so the same code runs where it is absent.

pg_cron can be CREATE EXTENSION'd in exactly one database per cluster, named by cron.database_name in postgresql.conf. The development database here has it, the test database deliberately does not, and host clusters vary. Every helper is therefore a guarded no-op when the extension is missing, which is what lets one migration run unchanged against both.

Idempotent through cron.schedule's upsert-by-name, so scheduling the same job twice updates it in place rather than creating a duplicate. That is exactly the contract a re-runnable migration needs, and it is why priv/migrations/cron/ scripts are class always.

On one cron job per thing

ergon_migration:partitioned_table_sql/2 schedules one weekly job per partitioned table, and that is fine at any table count.

Worth stating because Phase 5 went the other way for pgmq, consolidating a per-queue tick into one. The difference is not the number of jobs, it is what they do: a per-second tick that calls pg_notify is a notifying transaction per queue per second, and every one of those takes the global notification-queue lock at commit. A weekly job that creates partitions takes no such lock and runs thousands of times less often. Do not consolidate this one by analogy.