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
