Re: Tying an object's ownership to datdba - Mailing list pgsql-hackers

From John Naylor
Subject Re: Tying an object's ownership to datdba
Date
Msg-id CAFBsxsGf2uDCH3FDqKNQN5x67X60q=sjU3YBDbVFDnDnXo2BAQ@mail.gmail.com
Whole thread Raw
In response to Tying an object's ownership to datdba  (Noah Misch <noah@leadboat.com>)
Responses Re: Tying an object's ownership to datdba
List pgsql-hackers
On Mon, Dec 28, 2020 at 12:32 AM Noah Misch <noah@leadboat.com> wrote:
> [v2]

Hi Noah,

In the refactoring patch, there is a lingering comment reference to roles_has_privs_of(). Aside from that, it looks good to me. A possible thing to consider is an assert that is_admin is not null where we expect that.

The database owner role patch looks good as well.

> I ended up blocking DDL that creates role memberships involving the new role;
> see reasons in user.c comments.  Lifting those restrictions looked feasible,
> but it was inessential to the mission, and avoiding unintended consequences
> would have been tricky.  Views "information_schema.enabled_roles" and
> "information_schema.applicable_roles" list any implicit membership in
> pg_database_owner, but pg_catalog.pg_group and psql \dgS do not.  If this
> leads any reviewer to look closely at applicable_roles, note that its behavior
> doesn't match its documentation
> (https://postgr.es/m/flat/20060728170615.GY20016@kenobi.snowman.net).

Is this something that needs fixing separately?

--
John Naylor
EDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Jacob Champion
Date:
Subject: Re: Support for NSS as a libpq TLS backend
Next
From: Tom Lane
Date:
Subject: Re: default result formats setting