On Mon, Jun 24, 2024 at 03:53:46PM -0700, David G. Johnston wrote:
> pg_database_owner owns the initially created public schema and has an
> implicit membership list of one - the role owning the connected-to database.
> It exists to encourage and facilitate best practices regarding database
> administration. The primary rule being to avoid using superuser to own or
> do things.
This part restates much of the existing text in a slightly different order,
but I'm not sure it's an improvement. I like that it emphasizes the intent
of the role, but the basic description of the role is kind-of buried in the
first sentence. IMO the way this role works is confusing enough that we
ought to keep the basic facts at the very top. I might even add a bit of
fluff in an attempt to make things clearer:
The pg_database_owner role always has exactly one implicit,
situation-dependent member, namely the owner of the current database.
One other thing I like about your proposal is that it moves the bit about
the role initially owning the public schema much earlier. That seems like
possibly the most important practical piece of information to convey to
administrators. Perhaps that could be the very next thing after the basic
description of the role.
> The bootstrap superuser thus should connect to the postgres
> database and create a login role, with the createdb attribute, and then use
> that role to create and administer additional databases. In that context,
> this feature allows the creator of the new database to log into it and
> immediately begin working in the public schema.
IMHO the majority of this is too prescriptive, even if it's generally good
advice.
> As a result, in version 14, PostgreSQL no longer initially grants create
> and usage privileges, on the public schema, to the public pseudo-role.
IME we tend to shy away from adding too many historical details in the
documentation, and I'm not sure this information is directly related enough
to the role to include here.
> For technical reasons, pg_database_owner may not participate in explicitly
> granted role memberships. This is an easily mitigated limitation since the
> role that owns the database may be a group and any inheriting members of
> that group will be considered owners as well.
IIUC the intent of this is to expand on the following sentence in the
existing docs:
pg_database_owner cannot be a member of any role, and it cannot have
non-implicit members.
My instinct would be to do something like this:
pg_database_owner cannot be granted membership in any role, and no role
may be granted non-implicit membership in pg_database_owner.
IMHO the part about mitigating this limitation via groups is again too
prescriptive.
--
nathan