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 :
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 check
avant l'installation ou
gmake 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 35.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.
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 indiquées dans Tableau F.1, « Fonctions adminpack » fournissent un accès en écriture aux fichiers de la machine hébergeant le serveur. (Voir aussi les fonctions dans ???, qui fournissent un accès en lecture seule.) Seuls les fichiers stockés dans les répertoire de l'instance sont accessibles, même si un chemin relatif ou absolu est autorisé.
Tableau F.1. Fonctions adminpack
| Nom | Type de retour | Description |
|---|---|---|
| pg_catalog.pg_file_write(filename text, data text, append boolean) | bigint | Écrit ou ajoute dans un fichier texte |
| 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 journaux applicatifs dans le répertoire ciblé par log_directory |
pg_file_write écrit les data spécifiées dans le fichier nommé par filename. Si append est false, le fichier ne doit pas déjà exister. Si append est true, le fichier peut déjà exister, et les données y seront ajoutées si c'est le cas. Renvoit le nombre d'octets écrits.
pg_file_rename renomme un fichier. Si archivename est omis ou NULL, il renomme simplement oldname en newname (ce dernier ne doit pas déjà exister). Si archivename est fourni, il commence par renommer newname en archivename (qui ne doit pas déjà exister), puis il renomme oldname en newname. Dans le cas d'échec lors de la deuxième étape de renommage, il essaiera de renommer archivename en newname avant de renvoyer l'erreur. Renvoie true en cas de success, false si un des fichiers sources n'est pas présent ou modifiables. Tous les autres cas renvoient des erreurs.
pg_file_unlink supprime le fichier indiqué. Renvoie true en cas de succès, false si le fichier indiqué n'est pas présent ou si l'appel à unlink() échoue. Tous les autres cas renvoient des erreurs.
pg_logdir_ls renvoie les horodatages de démarrage et les noms de fichiers pour tous les journaux applicatifs compris dans le répertoire 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 indiquées dans ??? sont obsolètes et ne devraient plus être utilisées dans de nouvelles applications. Utilisez à la place celles indiquées dans Tableau 9.59, « Fonctions d'envoi de signal au serveur » et dans ???. Ces fonctions sont fournies dans adminpack uniquement pour des raisons de compatibilité pour les anciennes versions de pgAdmin.
Tableau F.2. Fonctions obsolètes de adminpack
| Nom | Type du retour | Description |
|---|---|---|
| pg_catalog.pg_file_read(filename text, offset bigint, nbytes bigint) | text | Autre nom pour pg_read_file() |
| pg_catalog.pg_file_length(filename text) | bigint | Identique à la colonne size renvoyée par la fonction pg_stat_file() |
| pg_catalog.pg_logfile_rotate() | integer | Autre nom pour pg_rotate_logfile(), mais notez qu'elle renvoie un entier 0 ou 1 à la place d'un booléen |
Postgres95 Release 0.01