that
  reads a particular catalog.
 </para>

 <para>
  Most PostgreSQL developers don't need to be directly concerned with
  the <acronym>BKI</acronym> file, but almost any nontrivial feature
  addition in the backend will require modifying the catalog header files
  and/or initial data files.  The rest of this chapter gives some
  information about that, and for completeness describes
  the <acronym>BKI</acronym> file format.
 </para>

 <sect1 id="system-catalog-declarations">
  <title>System Catalog Declaration Rules</title>

  <para>
   The key part of a catalog header file is a C structure definition
   describing the layout of each row of the catalog.  This begins with
   a <literal>CATALOG</literal> macro, which so far as the C compiler is
   concerned is just shorthand for <literal>typedef struct
   FormData_<replaceable>catalogname</replaceable></literal>.
   Each field in the struct gives rise to a catalog column.
   Fields can be annotated using the BKI property macros described
   in <filename>genbki.h</filename>, for example to define a default value
   for a field or mark it as nullable or not nullable.
   The <literal>CATALOG</literal> line can also be annotated, with some
   other BKI property macros described in <filename>genbki.h</filename>, to
   define other properties of the catalog as a whole, such as whether
   it is a shared relation.
  </para>

  <para>
   The system catalog cache code (and most catalog-munging code in general)
   assumes that the fixed-length portions of all system catalog tuples are
   in fact present, because it maps this C struct declaration onto them.
   Thus, all variable-length fields and nullable fields must be placed at
   the end, and they cannot be accessed as struct fields.
   For example, if you tried to
   set <structname>pg_type</structname>.<structfield>typrelid</structfield>
   to be NULL, it would fail when some piece of code tried to reference
   <literal>typetup-&gt;typrelid</literal> (or worse,
   <literal>typetup-&gt;typelem</literal>, because that follows
   <structfield>typrelid</structfield>).  This would result in
   random errors or even segmentation violations.
  </para>

  <para>
   As a partial guard against this type of error, variable-length or
   nullable fields should not be made directly visible to the C compiler.
   This is accomplished by wrapping them in <literal>#ifdef
   CATALOG_VARLEN</literal> ... <literal>#endif</literal> (where
   <literal>CATALOG_VARLEN</literal> is a symbol that is never defined).
   This prevents C code from carelessly trying to access fields that might
   not be there or might be at some other offset.
   As an independent guard against creating incorrect rows, we
   require all columns that should be non-nullable to be marked so
   in <structname>pg_attribute</structname>.  The bootstrap code will
   automatically mark catalog columns as <literal>NOT NULL</literal>
   if they are fixed-width and are not preceded by any nullable or
   variable-width column.
   Where this rule is inadequate, you can force correct marking by using
   <literal>BKI_FORCE_NOT_NULL</literal>
   and <literal>BKI_FORCE_NULL</literal> annotations as needed.
  </para>

  <para>
   Frontend code should not include any <filename>pg_xxx.h</filename>
   catalog header file, as these files may contain C code that won't compile
   outside the backend.  (Typically, that happens because these files also
   contain declarations for functions
   in <filename>src/backend/catalog/</filename> files.)
   Instead, frontend code may include the corresponding
   generated <filename>pg_xxx_d.h</filename> header, which will contain
   OID <literal>#define</literal>s and any other data that might be of use
   on the client side.  If you want macros or other code in a catalog header
   to be visible to frontend code, write <literal>#ifdef
   EXPOSE_TO_CLIENT_CODE</literal> ... <literal>#endif</literal> around that
   section to instruct <filename>genbki.pl</filename> to