Committed. Thank you for reviewing!
--
nathan
rebased (due to commit ccd3802, which introduced
pg_signal_autovacuum_worker)
--
nathan
>From c9e9c04c8edf3aaedc683c1c4e6811feb2c2c267 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Tue, 18 Jun 2024 11:38:40 -0500
Subject: [PATCH v5 1/1] revamp predefined roles documentation
---
On Wed, Jun 26, 2024 at 10:40:10AM -0400, Robert Haas wrote:
> On Tue, Jun 25, 2024 at 4:19 PM Nathan Bossart
> wrote:
>> Yeah, my options were to either separate the roles or to weaken the
>> ordering, and I guess I felt like the weaker ordering was slightly less
>> bad. The extra context in
On Tue, Jun 25, 2024 at 4:19 PM Nathan Bossart wrote:
> Yeah, my options were to either separate the roles or to weaken the
> ordering, and I guess I felt like the weaker ordering was slightly less
> bad. The extra context in some of the groups seemed worth keeping, and
> this probably isn't the
On Tue, Jun 25, 2024 at 1:19 PM Nathan Bossart
wrote:
> On Tue, Jun 25, 2024 at 04:04:03PM -0400, Robert Haas wrote:
> > Looking at this again, how happy are you with the way you've got
> > several roles per instead of one for each? I realize
> > that was probably part of the intent of the
On Tue, Jun 25, 2024 at 04:04:03PM -0400, Robert Haas wrote:
> Looking at this again, how happy are you with the way you've got
> several roles per instead of one for each? I realize
> that was probably part of the intent of the change, to move the data
> from below the table into the table, and
On Tue, Jun 25, 2024 at 3:26 PM Nathan Bossart wrote:
> I used this in v4 (with some minor changes).
Looking at this again, how happy are you with the way you've got
several roles per instead of one for each? I realize
that was probably part of the intent of the change, to move the data
from
On Tue, Jun 25, 2024 at 11:28:18AM -0500, Nathan Bossart wrote:
> On Tue, Jun 25, 2024 at 12:16:30PM -0400, Robert Haas wrote:
>> pg_database_owner is a predefined role for which membership consists,
>> implicitly, of the current database owner. It cannot be granted
>> membership in any role, and
On Tue, Jun 25, 2024 at 12:16:30PM -0400, Robert Haas wrote:
> pg_database_owner is a predefined role for which membership consists,
> implicitly, of the current database owner. It cannot be granted
> membership in any role, and no role can be granted membership in
> pg_database_owner. However,
On Tue, Jun 25, 2024 at 11:35 AM Nathan Bossart
wrote:
> 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
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
>
On Mon, Jun 24, 2024 at 2:53 PM Nathan Bossart
wrote:
> On Mon, Jun 24, 2024 at 02:44:33PM -0400, Robert Haas wrote:
>
> > I don't know what to do about pg_database_owner. I almost wonder if
> > that should be moved out of the table and documented as a special
> > case. Or maybe some more
On Mon, Jun 24, 2024 at 02:44:33PM -0400, Robert Haas wrote:
> I think the first two cases could be made more like each other by
> changing the varlistentires that are just about one setting to use the
> second format instead of the first, e.g. pg_checkpoint allows
> executing the CHECKPOINT
On Fri, Jun 21, 2024 at 11:40 AM Nathan Bossart
wrote:
> Done.
If you look at how the varlistentries begin, there are three separate patterns:
* Some document a single role and start with "Allow doing blah blah blah".
* Some document a couple of rolls so there are several paragraphs,
each
On Thu, Jun 20, 2024 at 07:57:16PM -0700, David G. Johnston wrote:
> I like this. Losing the table turned out to be ok. Thank you.
Awesome.
> I would probably put pg_monitor first in the list.
Done.
> + A user granted this role cannot however send signals to a backend owned
> by a superuser.
On Tue, Jun 18, 2024 at 9:52 AM Nathan Bossart
wrote:
> On Mon, Jun 17, 2024 at 02:10:22PM -0400, Robert Haas wrote:
> > On Thu, Jun 13, 2024 at 3:48 PM Nathan Bossart
> wrote:
> >> I think we could improve matters by abandoning the table and instead
> >> documenting these roles more like we
On Mon, Jun 17, 2024 at 02:10:22PM -0400, Robert Haas wrote:
> On Thu, Jun 13, 2024 at 3:48â¯PM Nathan Bossart
> wrote:
>> I think we could improve matters by abandoning the table and instead
>> documenting these roles more like we document GUCs, i.e., each one has a
>> section below it where
On Thu, Jun 13, 2024 at 3:48 PM Nathan Bossart wrote:
> I think we could improve matters by abandoning the table and instead
> documenting these roles more like we document GUCs, i.e., each one has a
> section below it where we can document it in as much detail as we want.
> Some of these roles
On Thu, Jun 13, 2024 at 01:05:33PM -0700, David G. Johnston wrote:
> One of the main attributes for the GUCs is their category. If we want to
> improve organization we'd need to assign categories first. We already
> implicitly do so in the description section where we do group them together
>
On Thu, Jun 13, 2024 at 12:48 PM Nathan Bossart
wrote:
> I think we could improve matters by abandoning the table and instead
> documenting these roles more like we document GUCs, i.e., each one has a
> section below it where we can document it in as much detail as we want.
>
>
One of the main
IMHO there are a couple of opportunities for improving the predefined roles
documentation [0]:
* Several of the roles in the table do not have corresponding descriptions
in the paragraphs below the table (e.g., pg_read_all_data,
pg_write_all_data, pg_checkpoint, pg_maintain,
21 matches
Mail list logo
