On Mon, Jun 17, 2024 at 02:10:22PM -0400, Robert Haas wrote:
> On Thu, Jun 13, 2024 at 3:48 PM Nathan Bossart <nathandbossart@gmail.com> 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 should probably be documented together (e.g.,
>> pg_read_all_data and pg_write_all_data), so the ordering is unlikely to be
>> perfect, but I'm hoping it would still be a net improvement.
>
> +1. I'm not sure about all of the details, but I like the general idea.
Here is a first try. I did pretty much exactly what I proposed in the
quoted text, so I don't have much else to say about it. I didn't see an
easy way to specify multiple ids and xreflabels for a given entry, so the
entries that describe multiple roles just use the name of the first role
listed. In practice, I think this just means you need to do a little extra
work when linking to one of the other roles from elsewhere in the docs,
which doesn't seem too terrible.
I like this. Losing the table turned out to be ok. Thank you.
I would probably put pg_monitor first in the list.
+ A user granted this role cannot however send signals to a backend owned by a superuser.
Remove "however", or put commas around it. I prefer the first option.
Do we really need to repeat "even without having it explicitly" everywhere?
+ This role does not have the role attribute BYPASSRLS set.
Even if it did, that attribute isn't inherited anyway...
"This role is still governed by any row level security policies that may be in force. Consider setting the BYPASSRLS attribute on member roles."
(assuming they intend it to be ALL data then doing the bypassrls even if they are not today using it doesn't hurt)
pg_stat_scan_tables - This explanation leaves me wanting more. Maybe give an example of such a function? I think the bar is set a bit too high just talking about a specific lock level.
"As these roles are able to access any file on the server file system,"
We forbid running under root so this isn't really true. They do have operating system level access logged in as the database process owner. They are able to access all PostgreSQL files on the server file system and usually can run a wide-variety of commands on the server.
"access, therefore great care should be taken"
I would go with:
"access. Great care should be taken"
Seems more impactful as its own sentence then at the end of a long multi-part sentence.
"server with COPY any other file-access functions." - s/with/using/
David J.
