Joel Jacobson <> writes:
> Currently, it's only possible to grant/revoke execute on functions to roles.

> I think it would be useful in many situations, both for documentation 
> purposes,
> but also for increased security, to in a precise way control what
> other function(s) are allowed to execute a specific function.

I think this is really *not* a good idea.  The entire permissions model
is built around granting permissions to roles, by other roles.  Allowing
non-role objects to hold permissions would be a complicated mess and
probably create security bugs.  Confusing function OIDs with role OIDs
is a likely example.  Another problem is that roles are installation-wide
while functions are not, and all the ACL catalog infrastructure is
designed for the permissions-holding entities to be installation-wide.
No doubt that could be dealt with, but it would be more complexity and
another fertile source of bugs.  Complexity in security-related concepts
is not a good thing.

It's not that hard, if you have needs like this, to make an owning role
for each such function.  You might end up with a lot of single-purpose
roles, but they could be grouped under one or a few group roles for most
purposes beyond the individual tailored grants.

                        regards, tom lane

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to