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, sauf si vous utilisez la cible « world » (voir Étape 2). Ils 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 SQL dans la base de données. À partir de PostgreSQL™, cela se fait en exécutant la commande CREATE EXTENSION(7). Dans une base de données neuve, vous pouvez simplement faire :
CREATE EXTENSION nom_module;
Cette commande doit être exécutée par un superutilisateur. Cela enregistre de nouveaux objets SQL dans la base de données courante, donc vous avez besoin d'exécuter cette commande dans chaque base de données où vous souhaitez l'utiliser. Autrement, exécutez-la dans la base de données template1 pour que l'extension soit copiée dans les bases de données créées après.
Beaucoup de modules vous permettent d'installer leurs objets dans le schéma de votre choix. Pour cela, ajoutez SCHEMA nom_schéma à la commande CREATE EXTENSION. Par défaut, les objets seront placés dans le schéma de création par défaut, donc généralement public.
Si votre base de données a été mise à jour par une sauvegarde puis un rechargement à partir d'une version antérieure à la 9.1 et que vous avez utilisé la version antérieure du module, vous devez utiliser à la place
CREATE EXTENSION nom_module FROM unpackaged;
Ceci mettra à jour les objets pré-9.1 du module dans une extension propre. Les prochaines mises à jour du module seront gérées par ALTER EXTENSION(7). Pour plus d'informations sur les mises à jour d'extensions, voir Section 35.15, « Empaqueter des objets dans une extension ».
L'adminpack fournit un certain nombre de fonctions de support que pgAdmin ou d'autres outils de gestion et d'administration peuvent utiliser pour fournir des fonctionnalités supplémentaires, comme la gestion à distance de journaux applicatifs.
Les fonctions ajoutées par adminpack ne peuvent être exécutées que par un super-utilisateur. La liste des fonctions est la suivante :
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()