<variablelist>

<varlistentry>

<term><acronym>AM</acronym></term>

<listitem>

<para>

<link linkend="glossary-am">Access Method</link>

</para>

</listitem>

</varlistentry>

<varlistentry>

<term><acronym>ANSI</acronym></term>

<listitem>

and understanding of sorting semantics. Therefore, they've acquired

some features that go beyond what would be needed just to support btree

indexes, and parts of the system that are quite distant from the

btreeAM make use of them.

btree<acronym>AM</acronym> make use of them.

</para>

</sect1>

</glossdef>

</glossentry>

<glossentry id="glossary-am">

<glossterm>Access Method</glossterm>

<glossdef>

<para>

Interfaces which <productname>PostgreSQL</productname> use in order to

access data in tables and indexes. This abstraction allows for adding

support for new types of data storage.

</para>

<para>

For more information, see <xref linkend="tableam" /> and

<xref linkend="indexam" />.

</para>

</glossdef>

</glossentry>

<glossentry>

<glossterm>Analytic function</glossterm>

<glosssee otherterm="glossary-window-function" />

the first; however they are permitted to require some restriction to

appear for the first index column, and this is signaled by setting

<structfield>amoptionalkey</structfield> false.

One reason that an indexAM might set

One reason that an index<acronym>AM</acronym> might set

<structfield>amoptionalkey</structfield> false is if it doesn't index

null values. Since most indexable operators are

strict and hence cannot return true for null inputs,

<para>

To implement an access method, an implementor will typically need to

implement anAM-specific type of tuple table slot (see

implement an<acronym>AM</acronym>-specific type of tuple table slot (see

<ulink url="https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/include/executor/tuptable.h;hb=HEAD">

<filename>src/include/executor/tuptable.h</filename></ulink>), which allows

code outside the access method to hold references to tuples of the AM, and