Greetings, * Jeff Davis (pg...@j-davis.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
signature.asc
Description: PGP signature