search

peterldowns / pgmigrate

a modern Postgres migrations CLI and library
MIT License
44 stars 3 forks source link

pgmigrate doesn't handle 'SET search_path TO...' #4

Open floitsch opened 5 months ago

floitsch commented 5 months ago

Our migrations contain SET search_path TO ... which drips pgmigrate. Even after changing the table-name to an "absolute" path like public.pgmigrate_migrations it would still not find it:

"ERROR: relation \"pgmigrate_migrations\" does not exist (SQLSTATE 42P01)"
peterldowns commented 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.

floitsch commented 5 months ago

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.