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
