Removing enum option referenced by foreign key

[swoutch]

Hello, I tried to migrate between those 2 schemas (removing the SK option of an enum referenced by a foreign key) and it fails. Do you consider supporting this case?

Here are the schemas

From:

CREATE TYPE language_code_enum AS ENUM ('FR', 'ES', 'SK'); -- the change is here

CREATE TABLE "language" (
    code language_code_enum PRIMARY KEY
);

CREATE TABLE "provider" (
    lang language_code_enum REFERENCES "language"(code)
);

Target:

CREATE TYPE language_code_enum AS ENUM ('FR', 'ES'); -- the change is here

CREATE TABLE "language" (
    code language_code_enum PRIMARY KEY
);

CREATE TABLE "provider" (
    lang language_code_enum REFERENCES "language"(code)
);

migra generated code:

alter type "public"."language_code_enum" rename to "language_code_enum__old_version_to_be_dropped";

create type "public"."language_code_enum" as enum ('FR', 'ES');

alter table "public"."language" alter column code type "public"."language_code_enum" using code::text::"public"."language_code_enum";

alter table "public"."provider" alter column lang type "public"."language_code_enum" using lang::text::"public"."language_code_enum";

drop type "public"."language_code_enum__old_version_to_be_dropped";

Here are the logs:

ALTER TYPE
CREATE TYPE
psql:mig.sql:5: ERROR:  foreign key constraint "provider_lang_fkey" cannot be implemented
DETAIL:  Key columns "lang" and "code" are of incompatible types: language_code_enum__old_version_to_be_dropped and language_code_enum.
psql:mig.sql:7: ERROR:  foreign key constraint "provider_lang_fkey" cannot be implemented
DETAIL:  Key columns "lang" and "code" are of incompatible types: language_code_enum and language_code_enum__old_version_to_be_dropped.
psql:mig.sql:9: ERROR:  cannot drop type language_code_enum__old_version_to_be_dropped because other objects depend on it
DETAIL:  column code of table language depends on type language_code_enum__old_version_to_be_dropped
column lang of table provider depends on type language_code_enum__old_version_to_be_dropped
HINT:  Use DROP ... CASCADE to drop the dependent objects too.

I know the primary issue is the bad schema design