Studio Exposed Functions Misrepresents PUBLIC EXECUTE Privilege As Revoked

The Studio query derives function access using aclexplode() and joins the grantee OID to pg_roles. PostgreSQL stores the built-in PUBLIC execute privilege as an ACL entry with grantee OID 0, which has no corresponding row in pg_roles, so the query never attributes that privilege to anon, authenticated, or service_role. PostgreSQL's effective permission check has_function_privilege() does include PUBLIC, hence the mismatch.

1. Create function public.studio_privilege_repro() without explicit ACL. 2. Run SELECT has_function_privilege('anon','public.studio_privilege_repro()','EXECUTE') -> true. 3. Open Studio Exposed functions; observe anon_execute=false, status=revoked. 4. POST /rest/v1/rpc/studio_privilege_repro with anon key; receives 200 and current_user=anon.

This query change is safe for read-only data but should be tested against large schemas because has_function_privilege may trigger additional catalog lookups. It also evaluates effective privileges, which can be broader than the explicit grants previously shown; operators may see functions become 'exposed' that were previously 'revoked'. Ensure any downstream access decisions do not rely solely on Studio status and use a dedicated RLS/policy check. Rollback is straightforward by restoring the previous aclexplode query if performance regresses, but the old behavior was incorrect.