The "postgres migration table existence check" feature added in v3.23.1 is a breaking change for non-default schema

[AndersSoee]

Before this change, the goose migrations "just worked", as long as the postgres searchPath was set to the correct schema.
With the new change, the existence check looks in the "Public" schema, where it is not present, and then fails when trying to create the table in the default schema (according to searchPath).

While we might get around this, by prefixing the migration table name with the schema, it then requires the migration to be schema aware, where it didn't need to be before.

[mfridman]

Apologies this broke you. We typically take backwards-incompatible changes quite seriously but this was one of those changes we thought would improve the implementation and affect very few folks, because

1. most (but not all) likely use the public schema
2. are already setting a goose table with the schema and/or specifying the schema in their migrations

Your feedback is valid though. Would a --schema-prefix flag or library option work for your use case?
We could make the table existence check opt-in, but the current implementation is more robust since it doesn't rely on error handling to detect tables. Several users reported that the previous approach created unnecessary log noise.

EDIT: I wonder if we could update the implementation to only search for the table name without specifying the schema, and optionally let users specify the schema, instead of defaulting to "public". That way, it should "just work", respecting the schemas specified in your search_path setting.

[mfridman]

I put up a PR to address this #883.

Thanks for flagging this. I believe this should resolve your issue while still maintaining the initial goal of improving table-checking logic.

[AndersSoee]

Thanks for the quick response!

I think this work for me.

I do believe though, that an even better approach would be to use select current_schema() , because that would return the schema where the table would be created.
Otherwise, you might run into issues, where the table exists in another schema.

I know that is even more of a corner case, but for example we run testcases in different schemas on the same database on some systems, to avoid some concurrency issues.

[AndersSoee]

PR: #884