Support for Schema

[chaitanyak59]

By default, automatically migrations table and migration-scripts are getting created in public schema.
It would be great if the library can provide command line argument.

Or something like json!
{
migrations_table: migrations,
migration_schema: auth_schema
}

[JCMais]

@ThomWright would you accept a PR with such feature?

[ThomWright]

@JCMais Please see the existing issues/PRs in this area. These include:

• Config migration table name #12
• Make doesTableExist check for table in current search path #33
• Check schema when checking for migrations table. #34
• Implement custom migration table name #48

I might accept a PR which solves these issues, is backwards-compatible and is well-tested.

It would probably be best to discuss how you propose to solve these problems before writing a PR. That way no one wastes time on PRs which don't satisfy the above and won't be accepted.

I can't remember exactly what all of the problems are with this, but I do remember that it's tricky. The information should be linked above.

Some of the problems:

• if the initial migration hash changes, that's a breaking change for every existing user
• the migrations table might not be in the public schema by default, it depends on the search path and schema access permissions

[JCMais]

All those problems could be avoided by a major version bump and doing breaking changes with the whole schema resolution / usage. Is that not something you are willing to do?

[ThomWright]

No, a major version bump doesn't cut it here IMO. There must be a way for users to upgrade to the next version relatively painlessly. If we could offer a way to do an automated upgrade or something, then I might consider it.

I'm thinking partly selfishly here. I maintain a bunch of services/databases using this library. I don't want to have to do long, risky, manual major version upgrades for all of them. I expect other users of this library will feel similarly.

I would consider it if it was just an API change, but messing with databases takes a bit more care, I think.

In the JS ecosystem, people tend to depend on many libraries. With high numbers of dependencies, even if individual libraries don't make breaking changes that often, application developers can see a lot of major version updates. Keeping up with it is time-consuming, and can be quite draining, especially when the updates involve manual work. Sorry this is a bit of a rant, but I think the onus is on us here to make it as little work as possible for people to upgrade.

Anyway, that's why I'm reluctant to just YOLO in the changes and release a new major version.

[mbyrne00]

FYI - if you're happy for your app to always have your schema set as the default then a workaround meantime is to add the following before you initialise postgres-migrations

process.env.PGOPTIONS="-c search_path=some_schema"

Did the trick for me.