From: =?UTF-8?Q?J=c3=bcrgen_Purtz?= <juergen@purtz.de>
Subject: Re: Shrinking SVG (Again)
To: pgsql-docs@lists.postgresql.org
Cc: Corey Huinker <corey.huinker@gmail.com>,
 Liudmila Mantrova <l.mantrova@gmail.com>
References: <20200214200106.GA12567@alvherre.pgsql>
Message-ID: <3f502222-487a-1937-9a77-0181bf72cd8b@purtz.de>
Date: Sat, 15 Feb 2020 09:19:32 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <20200214200106.GA12567@alvherre.pgsql>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Precedence: bulk


> So now we have two glossaries being proposed [1] [2], and they don't
> have much in common with each other.  What to do now?  If we can get the
> authors to agree on what patch to submit, we can move forward.
>
> I suggest to make a glossary be 0001, and then the other patches can be
> 0002 or further.

Yes, we should work on the glossary with priority because other things 
depend on it, not only the explanation of figures.

The two proposals differs in their nature: [1] is focused on PG-specific 
terms like WAL, Background Writer, Background Worker, ... and such terms 
that are broadly used but may differ from the meaning in other DBMS like 
Segment or Data Dictionary. It's only a starting point. Currently it 
misses the terms of important features like MVCC, Backup, Replication, 
... .  [2] also contains fundamental terms but is focused on universal 
terms of the DBMS community like SELECT, Null, Rollback, ... .

It's important to check, whether the existing documentation starts with 
something like "A <glossary-term> is a ...". In my opinion such 
redundancies aren't a problem as long as they don't contradict each 
other. On the contrary, I support this approach.

J. Purtz