Question about "Security Definer" functions in exposed schemas

[nCrafts]

This article states, "Security-definer functions should never be created in a schema in the "Exposed schemas" inside your API settings"

However this article demonstrates creating a Security-definer function in the public schema.

And then this third-party article shows you can use Security-definer functions to sometimes bypass the speed penalties of RLS. This is convenient.

Can someone elaborate why the Supabase documentation states that one should never create Security-definer functions in an exposed schema?

[GaryAustin1]

The 2nd one is a trigger function, it can only be called by the database and not from the API directly it is safe to use security definer.

The first one is for use in RLS policies, if you are using a function for RLS you cannot block access to authenticated or anon as it won't run in the RLS. So I assume to simplify things, there they say don't put it the public schema.

In not trigger and not RLS cases you can block access to functions by role with grants.

Also, if you know what you are doing you can protect security definer functions by setting a search path and using role or auth.uid() to limit what the user can do with the function.

More info:
https://supabase.com/docs/guides/database/functions#security-definer-vs-invoker
https://supabase.com/docs/guides/database/functions#function-privileges
And security definer function here: https://www.postgresql.org/docs/current/sql-createfunction.html