Open floitsch opened 5 months ago
Interesting, sorry for the trouble and thanks for the bug report. I am able to reproduce this on my own, and I will fix this.
Out of curiosity, can you share an example migration file and explain a little bit more about the reason you're adjusting the search path within your migrations? I haven't run into this before because I've never done that myself, and I'm curious to learn about this use case.
Out of curiosity, can you share an example migration file and explain a little bit more about the reason you're adjusting the search path within your migrations?
Of course. Example file: https://github.com/toitware/artemis-releases/blob/aa74252c3c3ee671407a172292743374cdf6934a/broker/supabase/migrations/20230207145057_initial.sql
In our setup we have two database components:
Since our broker is open source (https://github.com/toitware/artemis-releases/tree/main/broker/supabase/migrations) and can be run by our users we have all broker logic in its own schema (toit_artemis
) so that our customers can include it without messing up their own DB.
However, some table names, like devices
, exist both in the public (billing) schema and the broker.
For simplicity, I sometimes just set the search path to toit_artemis
in migration files that are only for the broker. This avoids some typing and accidental resolution from the broker to the billing schema.
Fwiw, I'm not a DB expert. There might be better ways to do this.
Our migrations contain
SET search_path TO ...
which dripspgmigrate
. Even after changing the table-name to an "absolute" path likepublic.pgmigrate_migrations
it would still not find it: