Greetings,
While looking through the GetUserId() usage in the backend, I couldn't help but notice a few rather questionable cases
that,in my view, should be cleaned up.
As a reminder, GetUserId() returns the OID of the user we are generally operating as (eg: whatever the 'role' is, as
GetUserId()respects SET ROLE). It does NOT include roles which we currently have the privileges of (that would be
has_privs_of_role()),nor roles which we could SET ROLE to (that's is_member_of_role, or check_is_... if you want to
justerror out in failure cases).
On to the list-
pgstat_get_backend_current_activity() Used to decide if the current activity string should be returned or not. In
myview, this is a clear case which should be addressed through has_privs_of_role() instead of requiring the user to
SETROLE to each role they are an inheirited member of to query for what the other sessions are doing.
pg_signal_backend() Used to decide if pg_terminate_backend and pg_cancel_backend are allowed. Another case which
shouldbe changed over to has_privs_of_role(), in my view. Requiring the user to SET ROLE for roles which they are
aninheirited member of is confusing as it's generally not required.
pg_stat_get_activity() Used to decide if the state information should be shared. My opinion is the same as above-
usehas_privs_of_role(). There are a number of other functions in pgstatfuncs.c with similar issues (eg:
pg_stat_get_backend_activity(), pg_stat_get_backend_client_port(), and others).
Changing these would make things easier for some of our users, I'm sure..
Thanks!
Stephen