enforcing security through RLS vs RPC
RLS
SolvedHi! During development, I realized that some of my users workloads (for example doing an insert on a table) require other inserts to be done in a transactional manner.
RPC functions are the solution to this.
However, I'm not sure how I should deal with security.
If I only want to use RPC for inserts, updates, deletes, i could remove all security policies to related tables and make the functions security definers, so the user can only access the database through that
Selects would still be affected by RLS policies, since I'm not making transactional changes to any tables
OR
I single out tables that are affected by transactional changes, and make the related functions "Security definers", all other functions would "security invokers".
Maybe the answer on how i should deal with RLS and RPC is different, but those are my thoughts.
RPC functions are the solution to this.
However, I'm not sure how I should deal with security.
If I only want to use RPC for inserts, updates, deletes, i could remove all security policies to related tables and make the functions security definers, so the user can only access the database through that
Selects would still be affected by RLS policies, since I'm not making transactional changes to any tables
OR
I single out tables that are affected by transactional changes, and make the related functions "Security definers", all other functions would "security invokers".
Maybe the answer on how i should deal with RLS and RPC is different, but those are my thoughts.
