Re: pg_auth_members.grantor is bunk

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Jacob Champion <jchampion@timescale.com>, Stephen Frost <sfrost@snowman.net>, "David G. Johnston" <david.g.johnston@gmail.com>, Mark Dilger <mark.dilger@enterprisedb.com>, Andrew Dunstan <andrew@dunslane.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2022-08-01T17:38:35Z
Lists: pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, Jul 31, 2022 at 2:34 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Indeed.  I've not read the patch, but I just wanted to mention that
>> the cfbot shows it as failing regression tests on all platforms.
>> Possibly a conflict with some recent commit?

> I can't see this on cfbot - either I don't know how to use it
> properly, which is quite possible, or the results aren't showing up
> because of the close of the July CommitFest.

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.

(Probably our nonexistent SOP manual for CFMs ought to say "don't
close the old CF till you've moved everything forward".)

			regards, tom lane



Commits

  1. Make role grant system more consistent with other privileges.

  2. Ensure that pg_auth_members.grantor is always valid.

  3. Remove the ability of a role to administer itself.

  4. Add tests of the CREATEROLE attribute

  5. Replace explicit PIN entries in pg_depend with an OID range test.

  6. Shore up ADMIN OPTION restrictions.

  7. Add pg_has_role() family of privilege inquiry functions modeled after the

  8. Align GRANT/REVOKE behavior more closely with the SQL spec, per discussion