PostgreSQL utilise de nombreux catalogues systèmes différents pour garder la trace de l'existence et les propriétés des objets des bases de données, tels que les tables et les fonctions. Il n'y a aucune différence physique entre un catalogue système et une table utilisateur standard, mais le code C des processus clients connaît la structure et les propriétés de chaque catalogue, et peut les manipuler directement à un bas niveau. Ainsi, par exemple, il est déconseillé de tenter de modifier la structure d'un catalogue à la volée ; cela casserait de nombreuses suppositions inscrites dans le code C sur comment les lignes du catalogues sont arrangées. Mais les structures des catalogues peuvent changer entre plusieurs versions majeures.

Les structures des catalogues sont déclarées dans des en-têtes de fichiers C spécialement formatées dans le répertoire src/include/catalog/ du code source. En particulier, il y a pour chaque catalogue un fichier d'en-tête nommé d'après le catalogue (par exemple, pg_class.h pour pg_class), qui définit l'ensemble des colonnes que le catalogue a, ainsi que certaines autres propriétés basique telles que son OID. D'autres fichiers cruciaux définissant la structure du catalogue incluent indexing.h, qui définit les index présents sur tous les catalogues systèmes, et toasting.h, qui définit les tables TOAST pour les catalogues qui en ont besoin.

Beaucoup des catalogues ont des données initiales qui doivent être chargées à l'intérieur durant la phase de « bootstrap » d'initdb, pour amener le système à un point où il est capable d'exécuter des ordres SQL. (Par exemple, pg_class.h doit contenir une entrée pour lui-même, ainsi qu'autant d'entrées pour chacun des autres catalogues système et index.) Ces données initiales sont conservées dans un format éditable dans des fichiers de données qui sont également stockés dans le répertoire src/include/catalog/. Par exemple, pg_proc.dat décrit toutes les lignes initiales qui doivent être insérées dans le catalogue pg_proc.

Pour créer les fichiers de catalogue et y charger ces données initiales, un processus client fonctionnant en mode « bootstrap » lit un fichier BKI (Backend Interface) contenant les commandes et les données initiales. Le fichier postgres.bki utilisé dans ce mode est préparé à partir des en-têtes et fichiers de données susmentionnés, en même temps que la création d'une distribution PostgreSQL, par un script Perl nommé genbki.pl. Bien qu'il soit spécifique à une version précise de PostgreSQL, postgres.bki ne dépend pas de la plateforme et est installé dans le sous-répertoire share de l'arborescence installée.

genbki.pl produit également des fichiers d'en-tête dérivés pour chaque catalogue, par exemple pg_class_d.h pour le catalogue pg_class. Ce fichier contient des définitions de macro automatiquement générées, et peut contenir d'autres macros, déclarations d'énumérations, etc qui peuvent être utiles pour du code C client qui lit un catalogue en particulier.

La plupart des développeurs de PostgreSQL n'ont pas besoin de se préoccuper directement du fichier BKI, mais presque toutes les fonctionnalités non triviales ajoutées dans les processus clients nécessiteront de modifier les fichiers d'en-tête de catalogue et/ou les fichiers de données initiales. Le reste de ce chapitre donne des informations sur ce sujet, et par soucis de complétude décrit le format de fichier BKI.