Hey, we need either RLS on columns, or RLS on views Right now it seems impossible to design complex applications with protected fields without the code getting too boilerplatey with security definers or something like that

Hey! I was reading about views and postgres adds RLS to views in version the latest version. We just gotta wait for Supabase to update postgres

A view is just a function of a table (or tables). If you create a function to perform the lookup and ensure it uses

SECURITY INVOKER

, you'll be able to create a view from that which has RLS enforced. Example: https://www.benburwell.com/posts/row-level-security-postgresql-views/ So it's already possible, but it's just not as straight-forward as having RLS controls directly on the view itself. Also, I wouldn't consider security definers 'boilerplatey'. They're a core part of Postgres, and there's literally 2 choices - runs as creator (

security definer

) or runs as executor (

security invoker

)

@Scott P I thought security invoker was part of the latest postgres version and the hosted Supabase instances are on an older version?

Nope, there's references to it even in the docs for PG 8.1 (released in 2005): https://www.postgresql.org/docs/8.1/sql-alterfunction.html

As I said in my original reply, you can workaround this without needing to wait for the new version - the link I posted explains the process

Ah because the correct auth is being passed in? And not from the person that created it?