Re: add new acronym "AM"
Daniel Gustafsson <daniel@yesql.se>
From: Daniel Gustafsson <daniel@yesql.se>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: alaa.attya91@gmail.com,
pgsql-docs@lists.postgresql.org
Date: 2023-11-13T12:38:57Z
Lists: pgsql-docs
Attachments
- v2-0001-doc-Add-acronym-and-glossary-term-for-Access-Meth.patch (application/octet-stream) patch v2-0001
> On 13 Nov 2023, at 12:20, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > > On 2023-Nov-13, Daniel Gustafsson wrote: > >> That's a fair point. It's sort of hard to refer back from the acronym list >> though since we don't have a single Access Method section but instead one for >> Indexes and one for Relations. In the attached diff I propose that we add a >> glossary entry for Access Method (suggested better wording much appreciated) >> which the acronym can refer to. Being such a core concept it doesn't seem like >> a bad idea to explain it. > > +1 for a glossary entry. > > + Access methods are the interfaces which > + <productname>PostgreSQL</productname> use in order to access relations > + and indexes. This abstraction allows for adding support for new > + types of tuple storage. For more information, see <xref linkend="indexam" /> > + and <xref linkend="tableam" />. > > We don't start the glossary definition with the term we're defining. > For example, we say > Atomicity > The property of a transaction that ... > we don't say > Atomicity > Atomicity is the property of ... > > So you would want your definition to be something like > "Interfaces which PostgreSQL use to ..." > > I'd say "data in tables and indexes" rather than "relations and > indexes", and "data storage" instead of "tuple storage". > > "For more information" should be its own <para>. Thanks, that makes it a lot better. v2 with the above changes attached. -- Daniel Gustafsson
Commits
-
doc: Add acronym and glossary term for Access Method
- 68387f9bdc82 17.0 landed