PostgreSQLLa base de données la plus sophistiquée au monde.

Version anglaise

F. Modules supplémentaires fournis

Cette annexe et la suivante contiennent 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é.

Cette annexe couvre les extensions et quelques autres modules plug-in du serveur disponibles dans le répertoire contrib du répertoire des sources.Annexe G, Programmes supplémentaires fournis couvre les programmes outils.

Lors de la construction à partir des sources de la distribution, ces extensions ne sont pas construites automatiquement, sauf si vous utilisez la cible « world » (voir Étape 2). Ils peuvent être construits et installés en exécutant :

make
make 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 :

make check
  

avant l'installation ou

make installcheck
  

une fois que le serveur PostgreSQL™ est démarré.

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 36.15, « Empaqueter des objets dans une extension ».

Néanmoins, notez que certains de ces modules ne sont pas des « extensions » dans ce sens, mais sont chargés sur le serveur d'une autre façon, par le biais de shared_preload_libraries. Voir la documentation de chaque module pour les détails.

F.1. adminpack

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. L'utilisation de toutes ces fonctions est restreinte aux superutilisateurs.

Les fonctions affichées dans Tableau F.1, « Fonctions de adminpack » fournissent des accès en écriture aux fichiers de la machine hébergeant le serveur. (Voir aussi les fonctions dans Tableau 9.86, « Fonctions d'accès générique aux fichiers », qui fournissent des accès en lecture seule.) Seuls les fichiers du répertoire principal de l'instance sont accessibles mais un chemin relatif ou absolu est permis.

Tableau F.1. Fonctions de adminpack

Nom Type en retour Description
pg_catalog.pg_file_write(filename text, data text, append boolean) bigint Écrit dans un fichier
pg_catalog.pg_file_rename(oldname text, newname text [, archivename text]) boolean Renomme un fichier
pg_catalog.pg_file_unlink(filename text) boolean Supprime un fichier
pg_catalog.pg_logdir_ls() setof record Liste les fichiers de trace du répertoire précisé par log_directory

pg_file_write écrit les données indiquées par le paramètre data dans le fichier indiqué par le paramètre filename. Si le paramètre append vaut false, le fichier ne doit pas déjà exister. S'il vaut true, le fichier peut déjà exister et les données y seront ajoutées. Renvoit le nombre d'octets écrits.

pg_file_rename renomme un fichier. Si archivename est omis ou vaut NULL, il renomme simplement oldname en newname (qui ne doit pas déjà exister). Si archivename est fourni, il renomme tout d'abord newname en archivename (qui ne doit pas déjà exister), puis il renomme oldname en newname. En cas d'échec à la deuxième étape, il essaiera de renommer archivename en newname avant de renvoyer l'erreur. Renvoit true en cas de succès, false si les fichiers sources ne sont pas présents ou modifiables. Dans tous les autres cas, elle renvoit une erreur.

pg_file_unlink supprime le fichier indiqué. Renvoit true en cas de succès, false si le fichier spécifié n'est pas présent ou si l'appel à unlink() échoue. Dans tous les autres cas, elle renvoit une erreur.

pg_logdir_ls renvoit l'horodatage et le chemin de tous les journaux applicatifs stockés dans le répertoire indiqué par le paramètre log_directory. Le paramètre log_filename doit avoir sa configuration par défaut (postgresql-%Y-%m-%d_%H%M%S.log) pour utiliser cette fonction.

Les fonctions affichées dans Tableau F.2, « Fonctions obsolètes de adminpack » sont obsolètes et ne devraient pas être utilisées dans les nouvelles applications. À la place, utilisez celles indiquées dans Tableau 9.77, « Fonctions d'envoi de signal au serveur » et Tableau 9.86, « Fonctions d'accès générique aux fichiers ». Ces fonctions sont fournies dans adminpack seulement pour assurer la compatibilité avec les anciennes versions de pgAdmin.

Tableau F.2. Fonctions obsolètes de adminpack

Nom Type en retour Description
pg_catalog.pg_file_read(filename text, offset bigint, nbytes bigint) text Nom alternatif pour pg_read_file()
pg_catalog.pg_file_length(filename text) bigint Identique à la colonne size renvoyée par pg_stat_file()
pg_catalog.pg_logfile_rotate() integer Nom alternatif pour pg_rotate_logfile(), mais notez qu'elle renvoit un entier (valant 0 ou 1) à la place d'un booléen