Cette annexe contient des informations concernant les modules disponibles dans le répertoire contrib de la distribution PostgreSQL™. Ce sont des outils de portage, des outils d'analyse, des fonctionnalités supplémentaires qui ne font pas partie du système PostgreSQL de base, principalement parce qu'ils s'adressent à une audience limitée ou sont trop expérimentaux pour faire partie de la distribution de base. Cela ne concerne en rien leur utilité.

Lors de la construction à partir des sources de la distribution, ces modules ne sont pas construits automatiquement. Il peuvent être construits et installés en exécutant :

gmake
gmake install

dans le répertoire contrib d'un répertoire des sources configuré ; ou pour ne construire et installer qu'un seul module sélectionné, on exécute ces commandes dans le sous-répertoire du module. Beaucoup de ces modules ont des tests de régression qui peuvent être exécutés en lançant la commande :

gmake installcheck

une fois que le serveur PostgreSQL™ est démarré. (gmake check n'est pas supporté ; un serveur de bases de données opérationnel est nécessaire pour réaliser ces tests, et le module doit avoir été construit et installé pour être testé.)

Lorsqu'une version packagée de PostgreSQL™ est utilisée, ces modules sont typiquement disponibles dans un package séparé, comme par exemple postgresql-contrib.

Beaucoup de ces modules fournissent de nouvelles fonctions, de nouveaux opérateurs ou types utilisateurs. Pour pouvoir utiliser un de ces modules, après avoir installé le code, il faut enregistrer les nouveaux objets dans la base de données en exécutant les commandes SQL contenus dans le fichier .sql fourni par le module. Par exemple :

psql -d nom_base -f SHAREDIR/contrib/module.sql

Ici, SHAREDIR est le répertoire « share » de l'installation (pg_config --sharedir indique de quel répertoire il s'agit). Dans la plupart de cas, le script doit être exécuté par un super-utilisateur de la base de données.

Le fichier .sql doit être exécuté dans chaque base de données où le module doit être disponible. Il peut également être exécuté dans la base template1 pour que le module soit automatiquement copié dans toute nouvelle base de données créée.

La première commande du fichier .sql peut être modifiée pour déterminer le schéma de la base où sont créés les objets. Par défaut, ils sont placés dans public.

Après une mise à jour majeure de PostgreSQL™, le script d'installation doit être réexécuté, même si les objets du module sont éventuellement créés par une sauvegarde de l'ancienne installation. Cela assure que toute nouvelle fonction est disponible et tout correction nécessaire appliquée.

int8 pg_catalog.pg_file_write(fname text, data text, append bool)
bool pg_catalog.pg_file_rename(oldname text, newname text, archivename text)
bool pg_catalog.pg_file_rename(oldname text, newname text)
bool pg_catalog.pg_file_unlink(fname text)
setof record pg_catalog.pg_logdir_ls()

/* Renommage des fonctions internes existantes pour une compatibilité
avec pgAdmin */
int8 pg_catalog.pg_file_read(fname text, data text, append bool)
bigint pg_catalog.pg_file_length(text)
int4 pg_catalog.pg_logfile_rotate()