Re: Glossary and initdb definition work for "superuser" and database/cluster - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: Glossary and initdb definition work for "superuser" and database/cluster
Date
Msg-id CAKFQuwY5VmHBZcGv5p4=0H6DRYUSuszMZaovreiDdFWEe4kufQ@mail.gmail.com
Whole thread Raw
In response to Re: Glossary and initdb definition work for "superuser" and database/cluster  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
On Fri, Nov 18, 2022 at 4:11 AM Alvaro Herrera <alvherre@alvh.no-ip.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.

pgsql-hackers by date:

Previous
From: Maxim Orlov
Date:
Subject: Re: [PoC] configurable out of disk space elog level
Next
From: David Geier
Date:
Subject: Re: Optimize join selectivity estimation by not reading MCV stats for unique join attributes