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-

    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.

    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.

    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



Attachment: signature.asc
Description: Digital signature

Reply via email to