Migration squash does not handle access privileges correctly

[asciiwhite]

Describe the bug

A migration which removes access privileges of an function is not handled correcty by a migration squash. Revoking privileges from public, anon and authenticated usually preserves the privileges to postgres and service_role. But after a migration squash the resulting migration only contains a revoke of public and a grant to service_role which allows anon and authenticated access privileges.

To Reproduce

1. Create a simple migration like

CREATE OR REPLACE FUNCTION "public"."test"()
    RETURNS void
    LANGUAGE "plpgsql"
    SECURITY DEFINER
    AS $$
BEGIN
END;
$$;

REVOKE ALL ON FUNCTION "public"."test"() FROM PUBLIC, anon, authenticated;

2. Validating the functions access privileges in SQL Editor shows expected result

SELECT grantee, privilege_type
FROM information_schema.role_routine_grants
WHERE routine_schema = 'public' AND routine_name = 'test';

| grantee      | privilege_type |
| ------------ | -------------- |
| postgres     | EXECUTE        |
| service_role | EXECUTE        |

3. Squash the migration into new migration, this now includes the correct function but wrong access privileges

CREATE OR REPLACE FUNCTION "public"."test"() RETURNS "void"
    LANGUAGE "plpgsql" SECURITY DEFINER
    AS $$
BEGIN
END;
$$;

REVOKE ALL ON FUNCTION "public"."test"() FROM PUBLIC;
GRANT ALL ON FUNCTION "public"."test"() TO "service_role";

4. Database reset with only the squashed migration, using SQL Editor to validating privileges

SELECT grantee, privilege_type
FROM information_schema.role_routine_grants
WHERE routine_schema = 'public' AND routine_name = 'test';

| grantee       | privilege_type |
| ------------- | -------------- |
| postgres      | EXECUTE        |
| anon          | EXECUTE        |
| authenticated | EXECUTE        |
| service_role  | EXECUTE        |

Expected behavior The access privileges should be the same with the squashed migration.

System information

• Version of CLI: v1.72.2
• Version of Postgres: 15.1.0.137

[smart-christian]

After further investigation the issue is not a result of supabase cli itself but of pg_dump.