<literal>0</literal> for the omitted operand of a unary
      operator.)
     </para>
    </listitem>

    <listitem>
     <para>
      The names of opclasses and opfamilies are only unique within an
      access method, so they are represented
      by <replaceable>access_method_name</replaceable><literal>/</literal><replaceable>object_name</replaceable>.
     </para>
    </listitem>

    <listitem>
     <para>
      In none of these cases is there any provision for
      schema-qualification; all objects created during bootstrap are
      expected to be in the <literal>pg_catalog</literal> schema.
     </para>
    </listitem>
   </itemizedlist>

   <para>
    <filename>genbki.pl</filename> resolves all symbolic references while it
    runs, and puts simple numeric OIDs into the emitted BKI file.  There is
    therefore no need for the bootstrap backend to deal with symbolic
    references.
   </para>

   <para>
    It's desirable to mark OID reference columns
    with <literal>BKI_LOOKUP</literal> or <literal>BKI_LOOKUP_OPT</literal>
    even if the catalog has no initial data that requires lookup.  This
    allows <filename>genbki.pl</filename> to record the foreign key
    relationships that exist in the system catalogs.  That information is
    used in the regression tests to check for incorrect entries.  See also
    the macros <literal>DECLARE_FOREIGN_KEY</literal>,
    <literal>DECLARE_FOREIGN_KEY_OPT</literal>,
    <literal>DECLARE_ARRAY_FOREIGN_KEY</literal>,
    and <literal>DECLARE_ARRAY_FOREIGN_KEY_OPT</literal>, which are
    used to declare foreign key relationships that are too complex
    for <literal>BKI_LOOKUP</literal> (typically, multi-column foreign
    keys).
   </para>
  </sect2>

  <sect2 id="system-catalog-auto-array-types">
   <title>Automatic Creation of Array Types</title>

   <para>
    Most scalar data types should have a corresponding array type (that is,
    a standard varlena array type whose element type is the scalar type, and
    which is referenced by the <structfield>typarray</structfield> field of
    the scalar type's <structname>pg_type</structname>
    entry).  <filename>genbki.pl</filename> is able to generate
    the <structname>pg_type</structname> entry for the array type
    automatically in most cases.
   </para>

   <para>
    To use this facility, just write an <literal>array_type_oid
    =&gt; <replaceable>nnnn</replaceable></literal> metadata field in the
    scalar type's <structname>pg_type</structname> entry, specifying the OID
    to use for the array type.  You may then omit
    the <structfield>typarray</structfield> field, since it will be filled
    automatically with that OID.
   </para>

   <para>
    The generated array type's name is the scalar type's name with an
    underscore prepended.  The array entry's other fields are filled from
    <literal>BKI_ARRAY_DEFAULT(<replaceable>value</replaceable>)</literal>
    annotations in <filename>pg_type.h</filename>, or if there isn't one,
    copied from the scalar type.  (There's also a special case
    for <structfield>typalign</structfield>.)  Then
    the <structfield>typelem</structfield>
    and <structfield>typarray</structfield> fields of the two entries are
    set to cross-reference each other.
   </para>
  </sect2>

  <sect2 id="system-catalog-recipes">
   <title>Recipes for Editing Data Files</title>

   <para>
    Here are some suggestions about the easiest ways to perform common tasks
    when updating catalog data files.
   </para>

   <formalpara>
    <title>Add a new column with a default to a catalog:</title>
    <para>
     Add the column to the header file with
     a <literal>BKI_DEFAULT(<replaceable>value</replaceable>)</literal>
     annotation.  The data file need only be adjusted by adding the field
     in existing rows where a non-default value is needed.
    </para>
   </formalpara>

   <formalpara>
    <title>Add a default value to an existing column that doesn't have
     one:</title>