Furthermore, if an OID is assigned, a C macro for that OID can be
    created by writing an <literal>oid_symbol
    =&gt; <replaceable>name</replaceable></literal> metadata field.
   </para>

   <para>
    Pre-loaded catalog rows must have preassigned OIDs if there are OID
    references to them in other pre-loaded rows.  A preassigned OID is
    also needed if the row's OID must be referenced from C code.
    If neither case applies, the <literal>oid</literal> metadata field can
    be omitted, in which case the bootstrap code assigns an OID
    automatically.
    In practice we usually preassign OIDs for all or none of the pre-loaded
    rows in a given catalog, even if only some of them are actually
    cross-referenced.
   </para>

   <para>
    Writing the actual numeric value of any OID in C code is considered
    very bad form; always use a macro, instead.  Direct references
    to <structname>pg_proc</structname> OIDs are common enough that there's
    a special mechanism to create the necessary macros automatically;
    see <filename>src/backend/utils/Gen_fmgrtab.pl</filename>.  Similarly
    &mdash; but, for historical reasons, not done the same way &mdash;
    there's an automatic method for creating macros
    for <structname>pg_type</structname>
    OIDs.  <literal>oid_symbol</literal> entries are therefore not
    necessary in those two catalogs.  Likewise, macros for
    the <structname>pg_class</structname> OIDs of system catalogs and
    indexes are set up automatically.  For all other system catalogs, you
    have to manually specify any macros you need
    via <literal>oid_symbol</literal> entries.
   </para>

   <para>
    To find an available OID for a new pre-loaded row, run the
    script <filename>src/include/catalog/unused_oids</filename>.
    It prints inclusive ranges of unused OIDs (e.g., the output
    line <literal>45-900</literal> means OIDs 45 through 900 have not been
    allocated yet).  Currently, OIDs 1&ndash;9999 are reserved for manual
    assignment; the <filename>unused_oids</filename> script simply looks
    through the catalog headers and <filename>.dat</filename> files
    to see which ones do not appear.  You can also use
    the <filename>duplicate_oids</filename> script to check for mistakes.
    (<filename>genbki.pl</filename> will assign OIDs for any rows that
    didn't get one hand-assigned to them, and it will also detect duplicate
    OIDs at compile time.)
   </para>

   <para>
    When choosing OIDs for a patch that is not expected to be committed
    immediately, best practice is to use a group of more-or-less
    consecutive OIDs starting with some random choice in the range
    8000&mdash;9999.  This minimizes the risk of OID collisions with other
    patches being developed concurrently.  To keep the 8000&mdash;9999
    range free for development purposes, after a patch has been committed
    to the master git repository its OIDs should be renumbered into
    available space below that range.  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.