fix(db): Exclude extensions schema from db pull #4168
Conversation
When running db pull, the schema diff was incorrectly including functions from the extensions schema, such as grant_pg_cron_access. This would generate a migration file that fails to apply locally due to permission errors, as these functions are owned by system roles. By adding extensions to the list of managed schemas, the CLI's diffing logic now correctly handles these objects, preventing it from generating migrations for platform-level functions. This resolves the local must be owner error.
Pull Request Test Coverage Report for Build 17787501473Warning: This coverage report may be inaccurate.This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
Details
💛 - Coveralls |
|
Yes, I think its reproducible on the experimental flag. with |
|
I can see that in the migra diff logic, there is a list of schemas to exclude, but we can't (user-created entites should be diffed). Migra tool itself has no support for excluding functions (in original repo), but cli is using supabase/migra fork. I might have to write a wrapper or extension for the two functions mentioned. This will work as a temporary fix. Is that fine? |
When running supabase db pull, migra generates CREATE OR REPLACE statements for the extensions.grant_pg_cron_access() and extensions.grant_pg_net_access() functions. These statements cause errors when running the migration locally, as the local postgres user is not the owner of these functions. This change filters the output of the migra diff to remove these two specific function definitions. This prevents the ownership errors while still allowing user-created entities in the extensions schema to be diffed and tracked in migrations.
|
@srini-abhiram before we spend more time on this solution, could you confirm whether your local postgres version matches the remote database? The supabase link
supabase db pull |
|
No, my local image is behind the remote version. |
|
My understanding is this: |
|
If there is a way to fetch the remote version, we could use the remote version as the shadow db, then apply migrations, thus eliminating the CREATE OR REPLACE FUNCTION code blocks. But it would require us to download the newer image and might lead to generating migration files that use new features the local database doesn't support, possibly breaking the current user implementations. This is a dilemma. |
|
One more solution we could try: |
Yes, that's my understanding too. Running
I don't think this is a dilemma because your local database should always be on the same version as the remote database. Otherwise, there's no guarantee that your local migrations will work the same way as on the remote database. |
True. The dilemma I was talking about is less of a dilemma and more of a trade-off. Users would be accustomed, and if they see that migrations are failing, they might go into a state of panic. Especially freshers like me. If we use the remote version as shadow db it would be less permissive (it would correctly fail when inconsistencies are found between local and remote), forcing the devs to fix the issues instead of letting them slide XD. But that is the best solution I could think of. But I am not sure how to get the remote version. I would be happy to implement this if you can give me some advice. Thanks! |
When running db pull, the schema diff was incorrectly including functions from the extensions schema, such as grant_pg_cron_access. This would generate a migration file that fails to apply locally due to permission errors, as these functions are owned by system roles. By adding extensions to the list of managed schemas, the CLI's diffing logic now correctly handles these objects, preventing it from generating migrations for platform-level functions. This resolves the local must be owner error.
What kind of change does this PR introduce?
Bug fix
What is the current behavior?
When a user runs supabase db pull, the command generates a migration file that includes CREATE OR REPLACE statements
for functions within the extensions schema (e.g., grant_pg_cron_access). When the user attempts to apply this migration to their local database (for example, by running supabase db reset), it fails with a permission error: ERROR: must be owner of function... (SQLSTATE 42501). This blocks the user's workflow, forcing them to manually remove these statements from the migration file each time they pull from the remote database (trivial task for fewer migrations but tedious task for bigger ones) as mentioned in #4163
What is the new behavior?
With this change, supabase db pull now correctly identifies the extensions schema as a schema managed by Supabase. As a result, it no longer includes platform-level functions from this schema in the user-facing migration file.
The db pull command now completes successfully without generating a migration that will fail on local execution.
Additional context
The fix was implemented by adding "extensions" to the internal list of managedSchemas in internal/db/pull/pull.go. This ensures the CLI's diffing engine treats the extensions schema with the same rules as other Supabase-managed schemas like auth and storage, resolving the root cause of the bug.