 Triggers sur événements avec PL/Perl
|
 
|
PL/Python - Langage de
procédures Python
|
Cette section liste les paramètres de configuration de PL/Perl.
Spécifie un code perl à exécuter lorsque l'interpréteur Perl est initialisé pour la première fois et avant qu'il soit spécialisé pour être utilisé par plperl ou plperlu. Les fonction SPI ne sont pas disponible lorsque ce code est exécuté. Si le code lève une erreur, il interrompra l'initialisation de l'interpréteur et la propagera à la requête originale, provoquant ainsi l'annulation de la transaction ou sous-transaction courante.
Le code Perl est limité à une seule ligne. Un code plus long peut être placé dans un module et chargé par on_init. Exemples:
plperl.on_init = 'require "plperlinit.pl"'
plperl.on_init = 'use lib "/my/app"; use MyApp::PgInit;'
Tous les modules chargés par plperl.on_init, directement ou indirectement, seront disponibles depuis plperl. Cela entraîne un problème de sécurité potentiel. Pour consulter la liste des modules chargés, vous pouvez utiliser :
DO 'elog(WARNING, join ", ", sort keys %INC)' LANGUAGE plperl;
L'initialisation aura lieu au sein du postmaster si la librairie plperl est incluse dans le paramètre shared_preload_libraries), auquel cas une plus grande attention doit être portée au risque de déstabiliser ce dernier. La raison principale d'utilisation de cette fonctionnalité est que les modules Perl chargés par plperl.on_init doivent être chargés seulement au démarrage de postmaster, et seront instantanément disponible sans surcoût dans chaque session individuelle. Néanmoins, gardez en tête que la surcharge est seulement évitée pour le premier interpréteur Perl utilisé par une session de base de données -- soit PL/PerlU, soit PL/Perl pour le premier rôle SQL qui appelle une fonction PL/Perl. Tout interpréteur Perl supplémentaire créé dans une session de base aura à exécuter plperl.on_init. De plus, sur Windows, il n'y aura aucun gain avec le préchargement car l'interpréteur Perl créé par le processus postmaster ne se propage pas aux processus fils.
Ce paramètre ne peut être positionné que dans le fichier postgresql.conf ou depuis la ligne de commande de démarrage du serveur.
Ces paramètres spécifient le code Perl à exécuter quand un interpréteur Perl est spécialisé respectivement pour plperl ou plperlu. Ceci n'arrivera que quand une fonction PL/Perl ou PL/PerlU est exécutée la première fois dans une session de base de données, ou quand un interpréteur supplémentaire doit être créé parce que l'autre langage a été appelé ou parce qu'une fonction PL/Perl a été appelée par un nouveau rôle SQL. Ceci suit toute initialisation réalisée par plperl.on_init. Les fonctions SPI ne sont pas disponibles quand ce code est exécuté. Le code Perl dans plperl.on_plperl_init est exécuté après le « verrouillage » de l'interpréteur, et donc il peut seulement réaliser des opérations de confiance.
Si le code lève une erreur, il interrompra l'initialisation et la propagera à la requête originale, provoquant ainsi l'annulation de la transaction ou sous-transaction courante. Toute action déjà réalisée dans Perl ne sera pas défaite ; néanmoins, cet interpréteur ne sera plus utilisé de nouveau. Si le langage est utilisé de nouveau, l'initialisation sera tentée de nouveau avec un nouvel interpréteur Perl.
Seuls les superutilisateurs peuvent modifier ces paramètres. Bien que ces paramètres peuvent être modifiés dans une session, de tels changements n'affecteront pas les interpréteurs Perl qui ont déjà été utilisés pour exécuter des fonctions.
Lorsqu'il est positionné à « true », les compilations des fonction PL/Perl suivantes auront le pragma strict activé. Ce paramètre n'affecte pas les fonctions déjà compilées au sein de la session courante.
Les fonctionnalités suivantes ne sont actuellement pas implémentées dans PL/Perl, mais peuvent faire l'objet de contributions généreuses de votre part.
Les fonctions PL/Perl ne peuvent pas s'appeler entre elles.
SPI n'est pas complètement implémenté.
Si vous récupérez des ensembles de données très importants en utilisant spi_exec_query, vous devez être conscient qu'ils iront tous en mémoire. Vous pouvez l'éviter en utilisant spi_query/spi_fetchrow comme montré précédemment.
Un problème similaire survient si une fonction renvoyant un ensemble passe un gros ensemble de lignes à PostgreSQL via return. Vous pouvez l'éviter aussi en utilisant à la place return_next pour chaque ligne renvoyée, comme indiqué précédemment.
Lorsqu'une session se termine normalement, et pas à cause d'une erreur fatale, tous les blocs END qui ont été définis sont exécutés. Actuellement, aucune autre action ne sont réalisées. Spécifiquement, les descripteurs de fichiers ne sont pas vidés automatiquement et les objets ne sont pas détruits automatiquement.