v0.1.0+commit.28d3fdd

fix(cli): add default_query_exec_mode=exec to connections by default

v0.0.7+commit.33cc123

fix(cmd): use --table-name flag in cli (#6)

Make CLI use the command-line flag for migration table name by
initializing a new `pgmigrate.Migrator` for each command, which allows
setting up the table name.

No API changes.

related to https://github.com/peterldowns/pgmigrate/issues/3

Co-authored-by: Mikko Seppänen <[email protected]>

v0.0.7+commit.da9de2e

fix(docker): use golang:1.22-alpine as base builder image

Fixes the docker build error on main, which is due to go1.20 not
understanding the `toolchain` directive in the `go.work` file. This
directive was added automatically by `go work` as part of the tidying
process.

```
 #30 [linux/amd64 builder 13/13] RUN go build   -ldflags "-X github.com/peterldowns/pgmigrate/cmd/pgmigrate/shared.Version=v0.0.7 -X github.com/peterldowns/pgmigrate/cmd/pgmigrate/shared.Commit=37e45fa"   -o /dist/pgmigrate   ./cmd/pgmigrate
```

https://github.com/peterldowns/pgmigrate/actions/runs/9586836776/job/26435591975

v0.0.7+commit.c17aafd

version(cli): v0.0.7

v0.0.7+commit.655bff6

fix: nix vendorHash

v0.0.7+commit.37e45fa

cleanup: just tidy

v0.0.6+commit.ea334dc

fix: load triggers even when they share a name (#5)

The `LoadTriggers` function was not properly returning all of the
triggers in the database, resulting in missing triggers in the resulting
`Schema` object and in the final results of `pgmigrate dump`. The root
cause was that triggers may share the same name as long as they're
attached to different tables, but the `SortKey()` implementation for a
`Trigger` only used the `trigger.Name`. This led to triggers colliding
during the sorting process, with just one trigger of a given name making
it to the result.

The fix is to use a combination of the trigger's table and its name
during the sorting process. I confirmed the problem and the fix by
writing unit tests — trigger loading was previously untested.

While developing this fix, I noticed that the golangci-lint
configuration was resulting in many lint errors. I updated this
configuration and fixed these lint errors. The only change that affects
behavior was that in the `migratorops` code, there were multiple cases
of a transaction `tx` being opened but then queries would be run against
the `db`, not the `tx`.

The breaking behavioral change is that in the `mark-applied`,
`mark-unapplied`, and `set-checksums` operations, *now* either all of
the migration records are updated or none of them are. Previously, some
could succeed while others later failed.

v0.0.6+commit.8b7bf02

nix: nix flake update

v0.0.6+commit.655a7cf

fix error when absolute path is provied in 'pgmigrate new --migration…

v0.0.6+commit.8c550a4

Improve installation instructions.