Esta sección enumera los parámetros de configuración que afectan a PL/Perl.
plperl.on_init (string)
#
Especifica el código Perl a ejecutar cuando se inicializa un intérprete Perl por primera
vez, antes de que se especialice para su uso por plperl o
plperlu.
Las funciones SPI no están disponibles cuando se ejecuta este código.
If the code fails with an error it will abort the initialization of
the interpreter and propagate out to the calling query, causing the
current transaction or subtransaction to be aborted.
El código Perl está limitado a una sola cadena. El código más largo se puede colocar
en un módulo y cargarse mediante la cadena on_init.
Ejemplos:
plperl.on_init = 'require "plperlinit.pl"' plperl.on_init = 'use lib "/my/app"; use MyApp::PgInit;'
Cualquier módulo cargado por plperl.on_init, ya sea directa o
indirectamente, estará disponible para su uso por plperl. Esto puede
crear un riesgo de seguridad. Para ver qué módulos se han cargado puedes usar:
DO 'elog(WARNING, join ", ", sort keys %INC)' LANGUAGE plperl;
La inicialización ocurrirá en el postmaster si la biblioteca plperl está
incluida en shared_preload_libraries, en cuyo
caso se debe prestar especial atención al riesgo de desestabilizar
el postmaster. La razón principal para hacer uso de esta característica
es que los módulos Perl cargados por plperl.on_init necesitan ser
cargados solo al inicio del postmaster, y estarán disponibles instantáneamente
sin sobrecarga de carga en las sesiones de bases de datos individuales. Sin embargo,
ten en cuenta que la sobrecarga se evita solo para el primer intérprete Perl
utilizado por una sesión de base de datos — ya sea PL/PerlU o
PL/Perl para el primer rol SQL que llama a una función PL/Perl. Cualquier
intérprete Perl adicional creado en una sesión de base de datos tendrá
que ejecutar plperl.on_init nuevamente. Además, en Windows no
habrá ningún ahorro por la precarga, ya que el intérprete Perl
creado en el proceso postmaster no se propaga a los procesos hijos.
Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor.
plperl.on_plperl_init (string)
plperl.on_plperlu_init (string)
#
Estos parámetros especifican el código Perl a ejecutar cuando un intérprete Perl
se especializa para plperl o
plperlu respectivamente. Esto sucederá cuando se ejecute por primera vez una función PL/Perl o
PL/PerlU en una sesión de base de datos, o cuando
se deba crear un intérprete adicional porque se llama al otro lenguaje
o un nuevo rol SQL llama a una función PL/Perl. Esto
sigue a cualquier inicialización realizada por plperl.on_init.
Las funciones SPI no están disponibles cuando se ejecuta este código.
El código Perl en plperl.on_plperl_init se ejecuta después de
“bloquear” el intérprete, y por lo tanto solo puede realizar
operaciones de confianza.
Si el código falla con un error, abortará la inicialización y se propagará a la consulta de llamada, causando que la transacción o subtransacción actual sea abortada. Cualquier acción ya realizada dentro de Perl no se deshará; sin embargo, ese intérprete no se usará de nuevo. Si el lenguaje se vuelve a utilizar, la inicialización se intentará de nuevo dentro de un intérprete Perl nuevo.
Solo los superusuarios pueden cambiar estos ajustes. Aunque estos ajustes se pueden cambiar dentro de una sesión, tales cambios no afectarán a los intérpretes Perl que ya se hayan utilizado para ejecutar funciones.
plperl.use_strict (boolean)
#
Cuando se establece en true, las compilaciones posteriores de funciones PL/Perl tendrán
habilitada la directiva strict. Este parámetro no afecta
a las funciones ya compiladas en la sesión actual.
Las siguientes características faltan actualmente en PL/Perl, pero serían contribuciones bienvenidas:
Las funciones PL/Perl no pueden llamarse entre sí directamente.
SPI aún no está completamente implementado.
Si estás recuperando conjuntos de datos muy grandes utilizando
spi_exec_query, debes tener en cuenta que
todos se guardarán en la memoria. Puedes evitar esto utilizando
spi_query/spi_fetchrow como
se ilustró anteriormente.
Un problema similar ocurre si una función que devuelve conjuntos pasa un
conjunto grande de filas de regreso a PostgreSQL a través de return. También puedes
evitar este problema utilizando en su lugar
return_next para cada fila devuelta, como se mostró
anteriormente.
Cuando una sesión termina normalmente, no debido a un error fatal, se ejecutan todos
los bloques END que se hayan definido.
Actualmente no se realizan otras acciones. Específicamente,
los manejadores de archivos no se limpian (flush) automáticamente y los objetos
no se destruyen automáticamente.