PostgreSQL utiliza muchos catálogos del sistema diferentes para realizar un seguimiento de la existencia y las propiedades de los objetos de la base de datos, como tablas y funciones. Físicamente no hay diferencia entre un catálogo del sistema y una tabla de usuario normal, pero el código C del backend conoce la estructura y las propiedades de cada catálogo y puede manipularlo directamente a bajo nivel. Por lo tanto, por ejemplo, no se recomienda intentar alterar la estructura de un catálogo sobre la marcha; eso rompería las suposiciones integradas en el código C sobre cómo se disponen las filas del catálogo. Pero la estructura de los catálogos puede cambiar entre versiones principales.

Las estructuras de los catálogos se declaran en archivos de cabecera C con un formato especial en el directorio src/include/catalog/ del árbol de código fuente. Para cada catálogo hay un archivo de cabecera que lleva el nombre del catálogo (por ejemplo, pg_class.h para pg_class), que define el conjunto de columnas que tiene el catálogo, así como algunas otras propiedades básicas como su OID.

Muchos de los catálogos tienen datos iniciales que deben cargarse en ellos durante la fase de «bootstrap» (arranque) de initdb, para llevar al sistema a un punto en el que sea capaz de ejecutar comandos SQL. (Por ejemplo, pg_class.h debe contener una entrada para sí mismo, así como una para cada uno de los otros catálogos e índices del sistema). Estos datos iniciales se guardan de forma editable en archivos de datos que también se almacenan en el directorio src/include/catalog/. Por ejemplo, pg_proc.dat describe todas las filas iniciales que se deben insertar en el catálogo pg_proc.

Para crear los archivos de catálogo y cargar estos datos iniciales en ellos, un backend que se ejecuta en modo bootstrap lee un archivo BKI (Backend Interface) que contiene comandos y datos iniciales. El archivo postgres.bki utilizado en este modo se prepara a partir de los archivos de cabecera y de datos antes mencionados, durante la compilación de una distribución de PostgreSQL, mediante un script Perl llamado genbki.pl. Aunque es específico para una versión particular de PostgreSQL, postgres.bki es independiente de la plataforma y se instala en el subdirectorio share del árbol de instalación.

genbki.pl también produce un archivo de cabecera derivado para cada catálogo, por ejemplo pg_class_d.h para el catálogo pg_class. Este archivo contiene definiciones de macros generadas automáticamente, y puede contener otras macros, declaraciones de enum, etc., que pueden ser útiles para el código C del cliente que lee un catálogo en particular.

La mayoría de los desarrolladores de PostgreSQL no necesitan preocuparse directamente con el archivo BKI, pero casi cualquier adición de una característica no trivial en el backend requerirá modificar los archivos de cabecera de los catálogos y/o los archivos de datos iniciales. El resto de este capítulo proporciona cierta información al respecto y, para completitud, describe el formato de archivo BKI.