Closed markalexander closed 5 months ago
I totally understand! I realize this is a feature a lot of folks want to, so it's next on my list!
Making this change isn't entirely trivial because, many objects like tables are namespaced by schema. So I can have some_schema_1.foobar
and some_schema_2.foobar
.
pg-schema-diff builds the migration plan using a web of dependencies. Initially, we built this system to only support public
, so a lot of internal representations of names do not include the schema. As a result, it would fall apart in scenarios where there are two identically named objects in different schemas -- failing out or generating entirely wrong plans.
I plan to plug away at this problem in the next week or so! pg-schema-diff is not my primary focus, so the timeline of this feature is pretty tentative.
Cool, thanks for replying. If you need any help testing it out, let me know—we've got a lot of non-default schemas and I'm sure some collisions between them without the schema-prefix namespacing.
And in general, thanks for working on this tool. Unlike other options it's lightweight and uses idiomatic Postgres features that we'd be using in hand-written migrations, so it's very appealing 🙂
Multi-schema support should be merged in now 🎉 The CLI still needs to be updated to actually support it!
Hi,
This is currently blocking our use-case.
Any insight into how much work this would be if we wanted to make a PR?
I.e. it just a case of adding an appropriate parameter and replacing the hard-coded instances of
public
, or is there some hidden complexity to it?From memory, some objects are namespaced unusually in Postgres, which might lead to conflicts? Though I only recall having those problems with the deeper features like RLS policies.
Thanks!