Typically, this will be done
    near the end of each development cycle, moving all OIDs consumed by
    patches committed in that cycle at the same time.  The script
    <filename>renumber_oids.pl</filename> can be used for this purpose.
    If an uncommitted patch is found to have OID conflicts with some
    recently-committed patch, <filename>renumber_oids.pl</filename> may
    also be useful for recovering from that situation.
   </para>

   <para>
    Because of this convention of possibly renumbering OIDs assigned by
    patches, the OIDs assigned by a patch should not be considered stable
    until the patch has been included in an official release.  We do not
    change manually-assigned object OIDs once released, however, as that
    would create assorted compatibility problems.
   </para>

   <para>
    If <filename>genbki.pl</filename> needs to assign an OID to a catalog
    entry that does not have a manually-assigned OID, it will use a value in
    the range 10000&mdash;11999.  The server's OID counter is set to 10000
    at the start of a bootstrap run, so that any objects created on-the-fly
    during bootstrap processing also receive OIDs in this range.  (The
    usual OID assignment mechanism takes care of preventing any conflicts.)
   </para>

   <para>
    Objects with OIDs below <symbol>FirstUnpinnedObjectId</symbol> (12000)
    are considered <quote>pinned</quote>, preventing them from being
    deleted.  (There are a small number of exceptions, which are
    hard-wired into <function>IsPinnedObject()</function>.)
    <application>initdb</application> forces the OID counter up
    to <symbol>FirstUnpinnedObjectId</symbol> as soon as it's ready to
    create unpinned objects.  Thus objects created during the later phases
    of <application>initdb</application>, such as objects created while
    running the <filename>information_schema.sql</filename> script, will
    not be pinned, while all objects known
    to <filename>genbki.pl</filename> will be.
   </para>

   <para>
    OIDs assigned during normal database operation are constrained to be
    16384 or higher.  This ensures that the range 10000&mdash;16383 is free
    for OIDs assigned automatically by <filename>genbki.pl</filename> or
    during <application>initdb</application>.  These
    automatically-assigned OIDs are not considered stable, and may change
    from one installation to another.
   </para>
  </sect2>

  <sect2 id="system-catalog-oid-references">
   <title>OID Reference Lookup</title>

   <para>
    In principle, cross-references from one initial catalog row to another
    could be written just by writing the preassigned OID of the referenced
    row in the referencing field.  However, that is against project
    policy, because it is error-prone, hard to read, and subject to
    breakage if a newly-assigned OID is renumbered.  Therefore
    <filename>genbki.pl</filename> provides mechanisms to write
    symbolic references instead.
    The rules are as follows:
   </para>

   <itemizedlist>

    <listitem>
     <para>
      Use of symbolic references is enabled in a particular catalog column
      by attaching <literal>BKI_LOOKUP(<replaceable>lookuprule</replaceable>)</literal>
      to the column's definition, where <replaceable>lookuprule</replaceable>
      is the name of the referenced catalog, e.g., <literal>pg_proc</literal>.
      <literal>BKI_LOOKUP</literal> can be attached to columns of
      type <type>Oid</type>, <type>regproc</type>, <type>oidvector</type>,
      or <type>Oid[]</type>; in the latter two cases it implies performing a
      lookup on each element of the array.
     </para>
    </listitem>

    <listitem>
     <para>
      It's also permissible to attach <literal>BKI_LOOKUP(encoding)</literal>
      to integer columns to reference character set encodings, which are
      not currently represented as catalog OIDs, but have a set of values
      known to <filename>genbki.pl</filename>.
     </para>
    </listitem>