Re: [PATCH] Add reloption for views to enable RLS

Dean Rasheed:
>> That is also the main reason I preferred naming it "security_invoker" -
>> it is consistent with other databases and eases transition from such
>> systems.
> [...]
>
> For my part, I find myself more and more convinced that
> "security_invoker" is the right name, because it matches the
> terminology used for functions, and in other database systems. I think
> the parallels between security invoker functions and security invoker
> views are quite strong.
>
> [...]
>
> When we come to write the release notes for this feature, saying that
> this version of PG now supports security invoker views is going to
> mean a lot more to people who already use that feature in other
> databases.
>
> What are other people's opinions?

All those points in favor of security_invoker are very good indeed. The 
main objection was not the term invoker, though, but the implicit 
association it creates as in "security_invoker=false behaves like 
security definer". But this is clearly wrong, the "security definer" 
semantics as used for functions or in other databases just don't apply 
as the default in PG.

I think renaming the reloption was a shortcut to avoid that association, 
while the best way to deal with that would be explicit documentation. 
Meanwhile, the patch has added a mention about CURRENT_USER, so that's a 
first step. Maybe an explicit mention that security_invoker=false, is 
NOT the same as "security definer" and explaining why would already be 
enough?

Best

Wolfgang