43.8. PL/Perl bajo el capó #

43.8.1. Configuración
43.8.2. Limitaciones y características faltantes

43.8.1. Configuración #

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.

43.8.2. Limitaciones y características faltantes #

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.