You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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;
Validating the functions access privileges in SQL Editor shows expected result
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";
Database reset with only the squashed migration, using SQL Editor to validating privileges
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
Expected behavior
The access privileges should be the same with the squashed migration.
System information
The text was updated successfully, but these errors were encountered: