-
-
Notifications
You must be signed in to change notification settings - Fork 202
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot reset database because "supabase db reset" tries to possibly drop types in wrong order #2207
Comments
I agree with your analysis. Ordering is indeed a problem. If you want to submit a PR, I'd be happy to merge it. |
@sweatybridge, thanks for the quick reply. Here is the PR with our proposed fix: #2208 |
Could you also report the postgres version of your In addition, could you also provide a SQL snippet for creating the types create type our_type_enum as enum ('a', 'b');
create domain our_type_domain as our_type_enum[];
create type our_type_composite as (one our_type_enum, two our_type_enum); |
Production: Postgres version 15.1.0.137 This is the migration for the enum type: CREATE TYPE our_enum_type AS ENUM ('a', 'b');
CREATE TABLE public.our_table
(
"id" UUID DEFAULT gen_random_uuid() NOT NULL,
...
"enum_type" our_enum_type NOT NULL,
...
PRIMARY KEY ("id")
); The type is not used in any other table, in no function, in no RLS policy, ... And we do not create the
|
Ic, thanks for clarifying. It seems like the underscore type is always created as a base type, which we can filter out with It is not possible for users to create a base type on Supabase because it requires superuser. Hence, there's also no need to drop a base type.
|
Thank you @sweatybridge, the problem is fixed in the latest release v1.163.4 |
Describe the bug
We cannot reset the database of our Supabase testing instance:
Our theory so far is, that the order in pg_type is responsible for this problem.
This is the part of the code which is executed by
supabase db reset
to drop all types:When we just executed the select part of this statement:
We found out that the order is different in our production, testing and local setup.
In production:
And in local:
But in testing:
(I omitted all columns I thought were not significant to this problem.)
In production and local the enum type
our_enum_type
comes before its array type. In testing the order is reversed.We think that this might the root of the problem.
Therefore, a possible fix could be to specify the order when dropping the types:
System information
The text was updated successfully, but these errors were encountered: