On Thu, Oct 14, 2021 at 1:43 PM Stephen Frost <sfr...@snowman.net> wrote: > I'm not sure that it's really inconsistent- if you want the function to > run as someone else, define it as SECURITY DEFINER and it will. If the > function is defined as SECURITY INVOKER then it'll run with the > privileges of the user invoking the function- which can be pretty handy > if, say, the function references CURRENT_USER.
That presumes that (1) the user who owns the view also owns the function and (2) the user who created the view and the function wants to permit people who query the view to call the function with any arguments, rather than only those arguments that would be passed by querying the view. Neither of those things is necessarily true. I am not really sure that we can get away with changing this, since it is long-established behavior. At least, if we do, we are going to have to warn people to watch out for backward-compatibility issues, some of which may not be things breaking functionally but rather having a different security profile. But, in a green field, I don't know why it's sane to suppose that if you query a view, the things in the view behave partly as if the user querying the view were running them, and partly as if the user owning the view were one of them. It seems much more logical for it to be one or the other. -- Robert Haas EDB: http://www.enterprisedb.com
