Closed hammerlscs closed 4 months ago
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: https://github.com/supabase/cli/pull/2208
Could you also report the postgres version of your production
and testing
projects? I just want to rule out the possibility of version mismatch.
In addition, could you also provide a SQL snippet for creating the types our_enum_type[]
and _our_enum_type
to help me reproduce? I tried a few things but none of them gave the same result as what you described.
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 Testing: Postgres version 15.1.0.116
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 our_enum_type[]
array type. It is created automatically by PostgreSQL:
Whenever a user-defined type is created, PostgreSQL automatically creates an associated array type, whose name consists of the element type's name prepended with an underscore [...].
Ic, thanks for clarifying. It seems like the underscore type is always created as a base type, which we can filter out with where typtype != 'b'
.
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.
The fourth form of CREATE TYPE creates a new base type (scalar type). To create a new base type, you must be a superuser. (This restriction is made because an erroneous type definition could confuse or even crash the server.)
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