On Wed, Oct 27, 2021 at 1:20 PM Bossart, Nathan <bossartn@amazon.com> wrote:
>
> On 10/26/21, 3:50 PM, "Joshua Brindle" <joshua.brindle@crunchydata.com> wrote:
> > Generally if a role is granted membership to another role with NOINHERIT
> > they must use SET ROLE to access the privileges of that role, however
> > with predefined roles the membership and privilege is conflated, as
> > demonstrated by:
>
> I think it makes sense that INHERIT/NOINHERIT should be respected for
> the predefined roles. I went through some of the old threads and
> commits for predefined roles, and I didn't find any mention of
> inheritance, so there might not be a strong reason it was done this
> way.
Thank you for looking into this. We believe this was a mistake and I
have a follow-up patch to remove is_member_of_role() from the header
to avoid it going forward.
At least one new pre-defined role patch (pg_maintenance) was recently
submitted using has_privs_of_role() so it seems like there is a need
for consistency regardless.
> I saw a few places in the docs that will likely need to be updated as
> well. For example, pg_freespacemap has this note:
>
> By default use is restricted to superusers and members of the pg_stat_scan_tables role.
>
> And I found at least one test (rolenames.sql) that fails due to the
> new ERROR message.
I'm new to contributing here but I've been told that the string
changes get taken care of later, is that not true?