Tom Lane wrote:
> Josh Berkus <josh@agliodbs.com> writes:
>
>>As said, I discussed this with Gaetano on IRC, and am not sure why things are
>>set up the way they are. If a user has permission on a view, shouldn't
>>that include permission on any functions executed by the view? If not, why
>>not?
>
>
> See prior discussions. The two stumbling blocks I can recall are:
>
> 1. Not breaking the ability of functions called by views to tell who the
> real user is --- see the filtering in the pg_statistic view for a handy
> real-world example. This constrains the possible design solutions.
>
> 2. Given the flexibility of the rule rewrite system, it's not unlikely
> that a user could find a way to execute any function invoked by a rule
> on data of his choosing. This is a bad idea if the function should not
> ordinarily be his to call.
>
> (Enlarging on point 2: there are no views. There are only rules, and
> any proposed solution has to be cast in terms of what happens with
> arbitrary rules.)
>
> I'm not saying we'll never do this, but I am saying that the topic has
> been visited before and no one's come up with an acceptable design.
Trust me, manage 167 views and 341 functions is a night mare in this way,
considering that I public some views and functions with a sort of XML-RPC.
As I already wrote on IRC, giving the executable permission on a table
( with security definer ) I allow users to call the function with any value
instead of values only presents in the view. I think this is a big limitation.
I'd like to fix this by myself but for lack of time and lack of postgres
code knowledge I'm stuck.
Regards
Gaetano Mendola
