On Wed, Oct 27, 2021 at 1:20 PM Bossart, Nathan <bossa...@amazon.com> wrote: > > On 10/26/21, 3:50 PM, "Joshua Brindle" <joshua.brin...@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?
