salsita/node-pg-migrate

The TypeScript FAQ defines "migrate": "node-pg-migrate", then presents four commands for running migrations without a subcommand: npm run migrate, pnpm run migrate, yarn migrate and bun run migrate. Following these examples invokes the CLI without arguments. The CLI entry point prints help and exits with an error instead of applying migrations. Update all four examples to pass up explicitly, for example npm run migrate up. Preserve the existing migration-creation example and TypeScript loading instructions. Validate the Markdown and ensure the examples agree with the CLI's existing subcommands.

Summary PostgreSQL can fire an UPDATE trigger only when certain columns are updated: AFTER UPDATE OF email, display_name ON accounts. node-pg-migrate can only express this by writing UPDATE OF … inside the free-text operation option, which is pasted into the SQL as-is. Column names that need quoting break, and decamelize doesn't apply to them. This proposes an updateOf option that takes column names and quotes them like every other column name in node-pg-migrate. Column lists work the same in every PostgreSQL version node-pg-migrate supports (they exist since 9.0; tested on 14 to 18 below), so it needs no version check. CockroachDB doesn't support them. Current behaviour operation is documented as INSERT, UPDATE[ OF ...], DELETE or TRUNCATE (docs), and createTrigger joins it into the statement unchanged (createTrigger.ts): pgm.createTrigger('accounts', 'accounts_on_membership', { when: 'AFTER', operation: ['INSERT', 'UPDATE OF is_member'], level: 'ROW', function: 'accounts_to

@Shinigami92 thanks for the detailed reviews on #1725. During the review, you identified that the same schema-qualified rename pattern exists in other operations. This issue tracks those remaining cases: renameType renameDomain renameView renameMaterializedView renameSequence renameIndex I checked the current main after #1725 was merged. These operations still have the same behavior pattern. Example: pgm.renameType({ schema: 'app', name: 'old_type' }, 'new_type'); The forward migration is valid, but automatic reversal can generate: ALTER TYPE "new_type" RENAME TO "app"."old_type"; The expected behavior is to preserve the source schema and use an unqualified destination: ALTER TYPE "app"."new_type" RENAME TO "old_type"; The goal is to investigate and reproduce each case, then prepare a focused PR with regression tests and PostgreSQL up/down validation, while keeping the public Name API unchanged. Before implementation, I would appreciate your preference on whether a small shared helpe