Re: add new acronym "AM"
От | Daniel Gustafsson |
---|---|
Тема | Re: add new acronym "AM" |
Дата | |
Msg-id | 4F49DE18-AF28-489E-B2CB-654EC6FC9C95@yesql.se обсуждение исходный текст |
Ответ на | Re: add new acronym "AM" (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Список | pgsql-docs |
> 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
Вложения
В списке pgsql-docs по дате отправления: