Re: Glossary and initdb definition work for "superuser" and database/cluster

On Fri, Nov 18, 2022 at 4:11 AM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
wrote:

> On 2022-Nov-02, David G. Johnston wrote:
>
> > Version 2 attached, some significant re-working. Starting to think that
> > initdb isn't the place for some of this content - in particular the stuff
> > I'm deciding to move down to the Notes section. Might consider moving
> some
> > of it to the Server Setup and Operation chapter 19 - Creating Cluster (or
> > nearby...) [1].
> >
> > I settled on "cluster owner" over "cluster user" and made the terminology
> > consistent throughout initdb and the glossary (haven't looked at chapter
> 19
> > yet). Also added it to the glossary.
>
> Generally speaking, I like the idea of documenting these things.
> However it sounds like you're not done with the wording and editing, so
> I'm not committing the whole patch, but it seems a good starting point
> to at least have some basic definitions. So I've extracted them from
> your patch and pushed those. You can already see it at
> https://www.postgresql.org/docs/devel/glossary.html

Agreed on the not quite ready yet, and that the glossary is indeed
self-contained enough to go in by itself at this point. Thank you for
doing that.

> I left out almost all the material from the patch that's not in the
> glossary proper, and also a few phrases in the glossary itself. Some of
> these sounded like security considerations rather than part of the
> definitions. I think we should have a separate chapter in Part III
> (Server Administration) that explains many security aspects; right now
> there's no hope of collecting a lot of very important advice in a single
> place, so a wannabe admin has no chance of getting things right. That
> seems to me a serious deficiency. A new chapter could provide a lot of
> general advice on every aspect that needs to be considered, and link to
> the reference section for additional details. Maybe part of these
> initdb considerations could be there, too.
>

I'll consider that approach as well as other spots in the documentation on
this next pass.

David J.