Cette section liste les paramètres de configuration de PL/Perl.
plperl.on_init
(string
)
#
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.
plperl.on_plperl_init
(string
)
plperl.on_plperlu_init
(string
)
#
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.
plperl.use_strict
(boolean
)
#
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.