v0.2.0+commit.b20af5f

fix: all `pgmigrate ops` commands were failing (#13)

Fixes https://github.com/peterldowns/pgmigrate/issues/10, which was
caused by https://github.com/peterldowns/pgmigrate/pull/13.

When I updated pgmigrate to start using a fully-qualified table name
(schema.tablename), I had to update the implementation to use a new
helper for referring to the migrations table:
`pgtools.QuoteTableAndSchema`. Because there were no tests for the
migrator ops commands, I forgot to update their implementations as well,
resulting in them all failing due to table-name quoting problems.

This PR:
- Adds tests for the migrator ops commands.
- Fixes the migrator ops commands by switching to
`pgtools.QuoteTableAndSchema`
- Also updates the migrator ops commands to *ensure* that a migrations
table exists when they run, which will create the migrations table if it
didn't already exist. This is a change in behavior; previously, if the
migrations table didn't exist, the migrator ops commands would fail with
an error. I can't remember why I made that decision and I believe that
this is more user-friendly behavior.

v0.2.0+commit.7c9317d

cleanup: turn off doCheck in flake

v0.2.0+commit.7b263ca

chore: cmd/pgmigrate,example to use [email protected] (#14)

Follow-up to https://github.com/peterldowns/pgmigrate/pull/13, updates
the example and cmd/pgmigrate modules to use the new v0.2.0 pgmigrate
library with the fixes for the ops commands.

I tested locally with `just build` and then running ops commands in the
CLI.

After merging, I'll tag cmd/pgmigrate with v0.2.0 as well.

I don't remember why I was tagging the example module, it's not
necessary, I'm going to stop doing that.

v0.1.0+commit.80d0b71

ci: speed up action workflows (#12)

- upgrade to golangci-lint-action@v6, which improves caching
- only check the nix flake builds
- split the nix build worfklow from the nix linting workflow
- install and cache nix things with the cachix actions

v0.1.0+commit.47b1421

dx: remove superfluous vscode extensions (#11)

These extensions aren't necessary for working in this
repository, they were included by accident.

v0.1.0+commit.2f6a72b

cleanup: stop bottling binaries for release

My homebrew recipes no longer do cask-style installations
of .tar.gz archives. Following the example of goreleaser,
the recipes directly download and link a binary for the
user's architecture.

This means that there is no need to pre-build the .tar.gz
bottle archives in this repo during the release workflow.

For more information, see https://github.com/peterldowns/homebrew-tap/commit/8bea68299f2e5f3045b3fc7e8056c498b07bcc8d

v0.1.0+commit.fec254d

version(cli,example): v0.1.0

v0.1.0+commit.d9f6b58

fix: flake (vendorHash)

After updating the CLI's reference to pgmigrate so that it depends on
v0.1.0 instead of the older v0.0.7, I forgot to update the nix build's
`vendorHash`, which changes every time the CLI's dependencies are
changed.

v0.1.0+commit.7f13363

fix: flake (vendorHash)

I have got to stop forgetting about this!

v0.1.0+commit.4125a0f

fix: allow SET search_path in migrations (#7)

An issue was reported in
https://github.com/peterldowns/pgmigrate/issues/4 that when a migration
executed `SET search_path TO ...`, pgmigrate would subsequently break by
failing to query against the table it uses to track which migrations
have been applied:

```
"ERROR: relation \"pgmigrate_migrations\" does not exist (SQLSTATE 42P01)"
```

This PR fixes this problem by making the following changes to solve the
problem:

- The `pgmigrate.Migrator` logic has been updated to properly
quote/escape the `migrator.TableName` value, allowing customers to use a
fully-qualified `schema.table_name` value that will resolve to the same
table in the same schema regardless of the current `search_path` setting
on the open connection.
- The `pgmigrate.DefaultTableName` is now fully-qualified with a leading
schema prefix, and becomes `public.pgmigrate_migrations` by default.
- This is a breaking change for anyone using pgmigrate and connecting to
their database with a `?search_path=something` connection string
parameter, where `something != public`.
- Because https://github.com/peterldowns/pgmigrate/pull/6 has been
merged, these affected customers can prevent any problems by setting the
migrations table to what it was previously being resolved to
(`something.pgmigrate_migrations`) using the `--table-name` cli argument
or `table_name:` yaml config key.

To confirm the fix, I added unit tests for:

- The schema-and-table name escaping logic.
- The exact scenario reported in #4 showing that pgmigrate now operates
correctly in the presence of migrations that include `SET search_path TO
...`.
- A potentially unexpected consequence of using `SET search_path TO ...`
in one migration, which is that subsequent migrations may execute with a
different `search_path`.

My overall recommendation is that if you're modifying
connection-specific settings inside of a migration, you:
- ALWAYS re-set the relevant settings at the beginning of every
migration, to ensure that your migrations run with the settings you
expect.
- Consider using `SET LOCAL` instead of `SET` to scope the changes to
just the transaction that is executing your migration, to help prevent
accidental "contamination" of the connection state that may change the
behavior of subsequent migrations.
- Generally try to avoid modifying connection settings inside
migrations, it just makes everything more confusing.

With this PR, `pgmigrate`'s correctness will no longer be affected by
the use of `SET search_path TO ...` in a migration.