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 just error 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 my view, this is a clear case which should be addressed through has_privs_of_role() instead of requiring the user to SET ROLE 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 should be changed over to has_privs_of_role(), in my view. Requiring the user to SET ROLE for roles which they are an inheirited 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- use has_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
Description: Digital signature