(<acronym>LSB</acronym>) to 31 (<acronym>MSB</acronym>).  Note that
this field is stored in network byte order (most significant byte first),
as are all the integer fields used in the file format.  Bits
16&ndash;31 are reserved to denote critical file format issues; a reader
should abort if it finds an unexpected bit set in this range. Bits 0&ndash;15
are reserved to signal backwards-compatible format issues; a reader
should simply ignore any unexpected bits set in this range. Currently
only one flag bit is defined, and the rest must be zero:
        <variablelist>
         <varlistentry>
          <term>Bit 16</term>
          <listitem>
           <para>
            If 1, OIDs are included in the data; if 0, not. Oid system columns
            are not supported in <productname>PostgreSQL</productname>
            anymore, but the format still contains the indicator.
           </para>
          </listitem>
         </varlistentry>
        </variablelist></para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>Header extension area length</term>
      <listitem>
       <para>
32-bit integer, length in bytes of remainder of header, not including self.
Currently, this is zero, and the first tuple follows
immediately.  Future changes to the format might allow additional data
to be present in the header.  A reader should silently skip over any header
extension data it does not know what to do with.
       </para>
      </listitem>
     </varlistentry>
    </variablelist>
    </para>

    <para>
The header extension area is envisioned to contain a sequence of
self-identifying chunks.  The flags field is not intended to tell readers
what is in the extension area.  Specific design of header extension contents
is left for a later release.
    </para>

    <para>
     This design allows for both backwards-compatible header additions (add
     header extension chunks, or set low-order flag bits) and
     non-backwards-compatible changes (set high-order flag bits to signal such
     changes, and add supporting data to the extension area if needed).
    </para>
   </refsect3>

   <refsect3>
    <title>Tuples</title>
    <para>
Each tuple begins with a 16-bit integer count of the number of fields in the
tuple.  (Presently, all tuples in a table will have the same count, but that
might not always be true.)  Then, repeated for each field in the tuple, there
is a 32-bit length word followed by that many bytes of field data.  (The
length word does not include itself, and can be zero.)  As a special case,
-1 indicates a NULL field value.  No value bytes follow in the NULL case.
    </para>

    <para>
There is no alignment padding or any other extra data between fields.
    </para>

    <para>
Presently, all data values in a binary-format file are
assumed to be in binary format (format code one).  It is anticipated that a
future extension might add a header field that allows per-column format codes
to be specified.
    </para>

    <para>
To determine the appropriate binary format for the actual tuple data you
should consult the <productname>PostgreSQL</productname> source, in
particular the <function>*send</function> and <function>*recv</function> functions for
each column's data type (typically these functions are found in the
<filename>src/backend/utils/adt/</filename> directory of the source
distribution).
    </para>

    <para>
If OIDs are included in the file, the OID field immediately follows the
field-count word.  It is a normal field except that it's not included in the
field-count.  Note that oid system columns are not supported in current
versions of <productname>PostgreSQL</productname>.
    </para>
   </refsect3>

   <refsect3>
    <title>File Trailer</title>

    <para>
     The file trailer consists of a 16-bit integer word containing -1.  This
     is easily distinguished from a tuple's field-count word.
    </para>

    <para>
     A reader should report an error if a field-count word is neither -1