0010_security_definer_view is not in general an error

[tvogel]

https://github.com/supabase/splinter/blob/b8850303e7e92893023256cf0a925f5aed41d143/docs/0010_security_definer_view.md?plain=1#L2

In general, SECURITY DEFINER views have their legitimate use just as user-defined functions have as well. In particular, it allows to define specific RLS rules that are suitable for the respective view and blacklisting their use in the linter seems harsh to me.

Please see https://github.com/supabase/splinter/issues/80 for a case that I see as a useful example for using a SECURITY DEFINER view with custom RLS in the WHERE clause.

[olirice]

I agree that security definer views aren't inherently a problem.

supabase/splinter is slightly opinionated based on our views on how to build simple/safe/scalable applications. Security definer views can be a piece of the application but in our experience having them exposed directly via APIs can lead to complexity and unexpected security gaps.

We recommend implementing security in once place (on each table) and having that apply to everything (direct DB connections, REST/GraphQL/Realtime users, etc). Security definer views poke a hole in that safety, which is an unexpected default for less experienced postgres users.

We only lint for security definer views on the search path so you could move them to a different schema to remove the lint, or if you're 100% confident you've got the security how you want it with the where clause in a security definer view, you can ignore/accept the lint error