|From:||Stephen Frost <sfrost(at)snowman(dot)net>|
|Subject:||Review of GetUserId() Usage|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
|Next Message||Heikki Linnakangas||2014-09-23 06:33:37||Re: Commitfest status|
|Previous Message||Peter Geoghegan||2014-09-23 06:15:36||Re: RLS feature has been committed|