On Mon, Aug 1, 2022 at 3:51 PM Robert Haas <robertmh...@gmail.com> wrote: > On Mon, Aug 1, 2022 at 1:38 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > >> I think the latter --- the cfbot thinks the July CF is no longer relevant, > > but Jacob hasn't yet moved your patches forward. You could wait for > > him to do that, or do it yourself. > > Done. New patches attached.
Well, CI isn't happy with this, and for good reason: ALTER GROUP regress_priv_group2 ADD USER regress_priv_user2; -- duplicate -NOTICE: role "regress_priv_user2" has already been granted membership in role "regress_priv_group2" by role "rhaas" +NOTICE: role "regress_priv_user2" has already been granted membership in role "regress_priv_group2" by role "postgres" The problem here is that I revised the error message to include the name of the grantor, since that's now a part of the identity of the grant. It would be misleading to say, as we did previously... NOTICE: role "regress_priv_user2" is already a member of role "regress_priv_group2" ...because them being in the group isn't relevant so much as them being in the group by means of the same grantor. However, I suspect that I can't persuade all of you that we should hard-code the name of the bootstrap superuser as "rhaas", so this test case needs some alteration. I found, however, that the original intent of the test case couldn't be preserved with the patch as written, because when you grant membership in one role to another role as the superuser or a CREATEROLE user, the grant is attributed to the bootstrap superuser, whose name is variable, as this test failure shows. Therefore, to fix the test, I needed to use ALTER GROUP as a non-CREATEROLE user, some user created as part of the test, for the results to be stable. But that was impossible, because even though "GRANT user_name TO group_name" requires *either* CREATEROLE *or* ADMIN OPTION on the group, the equivalent command "ALTER GROUP group_name ADD USER user_name" requires specifically CREATEROLE. I debated whether to fix that inconsistency or just remove this test case and eventually came down on the side of fixing the inconsistency, so the attached version does it that way. -- Robert Haas EDB: http://www.enterprisedb.com
v5-0001-Ensure-that-pg_auth_members.grantor-is-always-val.patch
Description: Binary data
v5-0002-Make-role-grant-system-more-consistent-with-other.patch
Description: Binary data
