Re: should we allow users with a predefined role to access pg_backend_memory_contexts view and pg_log_backend_memory_contexts function?

Greetings,

* Jeff Davis (pgsql(at)j-davis(dot)com) wrote:
> On Fri, 2021-10-15 at 09:08 -0400, Robert Haas wrote:
> > I think we'd at least need to check that the view owner has execute
> > permission on the function. I'm not sure whether there are any other
> > gotchas.
>
> Right, like we do for tables in a view now.
>
> The alternative is not very appealing: that we have to document a lot
> of currently-undocumented internal functions like
> pg_get_backend_memory_contexts(), pg_lock_status(), etc., so that users
> can grant fine-grained permissions.

Being undocumented and being an 'internal function' aren't quite the
same thing.. pg_lock_status() is available for users to call and even
has a description which they can review with \dfS+ and is "view system
lock information", not to mention that it calls GetLockStatusData which
is explicitly documented as "for use in a user-level reporting
function".

I do recongize that it's not in the formal documentation currently,
though I'm not quite sure I understand why that's the case when we
document things like pg_stat_get_activity(). While I appreciate that it
isn't really addressing the complaint you have that it'd be nice if we
made things simpler for administrators by making it so they don't have
to GRANT access to both the view and the function, and I can see how
that would be nice, it seems like we should probably be documenting
these functions too and I don't know that it's correct to characterize
them as 'internal'. I can't say that I know exactly where the line is
between being a user-level function and an 'internal' function is, but
being used in a view that's created for users to query seems to me to
make it closer to user-level than, say, aclitemin.

Thanks,

Stephen