# Reproduce the index hotfix

The article uses Ptah 0.7.0 and PostgreSQL 18.6. Use two empty disposable
databases. `STAGING_URL` and `PRODUCTION_URL` are their connection URLs.

## Starting state

Start with only the `1789992000_create_orders` migration pair in your working
`migrations/` directory. The files provided here include the completed example,
so add the `1789992060_add_customer_index` pair only when the article reaches
that step. `before.sql` describes the schema before the hotfix; `schema.sql`
describes the intended result.

Hash the initial directory:

```console
ptah migrations hash --dir migrations
```

Apply the initial migration to staging:

```console
ptah migrations up --db-url "$STAGING_URL" --migrations-dir migrations --verify-sum
```

Apply it to production:

```console
ptah migrations up --db-url "$PRODUCTION_URL" --migrations-dir migrations --verify-sum
```

Run the SQL in `hotfix.sql` against the production stand-in using your
PostgreSQL client. Continue with the article's direct Ptah commands and its
inspection query. Add the second migration pair at the point shown, then hash
and apply it as described.

The down migration removes the index even when it predates adoption. Test
rollback only on a disposable database where removing that index is intended.

## Recorded results

`expected/` contains the output excerpts shown in the article.
`verified.json` records the tested versions, SQL file hashes, and results.
The verification covered both starting states, replay from an empty database,
preservation of the existing index, and rollback. It also confirmed that an
index with the right name and wrong column survives `IF NOT EXISTS` and still
produces a schema difference.

From the repository root, `npm run check:examples` checks that the article's
named SQL and output blocks match these files. It does not run database commands.

Remove the disposable databases when finished. To repeat the walkthrough,
start with empty databases and only the initial migration pair.