40.1. Instalación de lenguajes procedimentales

40.1. Instalación de lenguajes procedimentales
Prev	Up	Chapter 40. Lenguajes procedimentales	Home	Next

40.1. Instalación de lenguajes procedimentales #

Un lenguaje procedimental debe ser “instalado” en cada base de datos donde se vaya a utilizar. Sin embargo, los lenguajes procedimentales instalados en la base de datos template1 están disponibles automáticamente en todas las bases de datos creadas posteriormente, ya que sus entradas en template1 se copiarán mediante CREATE DATABASE. Así, el administrador de la base de datos puede decidir qué lenguajes están disponibles en qué bases de datos y, si lo desea, puede hacer que algunos lenguajes estén disponibles por defecto.

Para los lenguajes suministrados con la distribución estándar, solo es necesario ejecutar CREATE EXTENSION language_name para instalar el lenguaje en la base de datos actual. El procedimiento manual descrito a continuación solo se recomienda para instalar lenguajes que no han sido empaquetados como extensiones.

Instalación manual de un lenguaje procedimental

Un lenguaje procedimental se instala en una base de datos en cinco pasos, los cuales deben ser realizados por un superusuario de la base de datos. En la mayoría de los casos, los comandos SQL requeridos deberían empaquetarse como el script de instalación de una “extensión”, de modo que se pueda utilizar CREATE EXTENSION para ejecutarlos.

El objeto compartido para el manejador del lenguaje debe compilarse e instalarse en un directorio de bibliotecas adecuado. Esto funciona de la misma manera que la construcción e instalación de módulos con funciones C normales definidas por el usuario; consulta Section 36.10.5. A menudo, el manejador del lenguaje dependerá de una biblioteca externa que proporcione el motor del lenguaje de programación real; de ser así, esta también debe instalarse.
El manejador debe declararse con el comando
```
CREATE FUNCTION handler_function_name()
    RETURNS language_handler
    AS 'path-to-shared-object'
    LANGUAGE C;
```
El tipo de retorno especial language_handler le indica al sistema de la base de datos que esta función no devuelve uno de los tipos de datos SQL definidos y no se puede utilizar directamente en sentencias SQL.
Opcionalmente, el manejador del lenguaje puede proporcionar un manejador “inline” (en línea) que ejecute bloques de código anónimos (comandos DO) escritos en este lenguaje. Si el lenguaje proporciona una función de manejador en línea, declárala con un comando como
```
CREATE FUNCTION inline_function_name(internal)
    RETURNS void
    AS 'path-to-shared-object'
    LANGUAGE C;
```
Opcionalmente, el manejador del lenguaje puede proporcionar una función de “validación” que compruebe la corrección de la definición de una función sin llegar a ejecutarla. La función de validación es llamada por CREATE FUNCTION si existe. Si el lenguaje proporciona una función de validación, declárala con un comando como
```
CREATE FUNCTION validator_function_name(oid)
    RETURNS void
    AS 'path-to-shared-object'
    LANGUAGE C STRICT;
```
Finalmente, el PL debe declararse con el comando
```
CREATE [TRUSTED] LANGUAGE language_name
    HANDLER handler_function_name
    [INLINE inline_function_name]
    [VALIDATOR validator_function_name] ;
```
La palabra clave opcional TRUSTED especifica que el lenguaje no otorga acceso a datos a los que el usuario no tendría acceso de otro modo. Los lenguajes de confianza (trusted) están diseñados para usuarios comunes de la base de datos (aquellos sin privilegios de superusuario) y les permite crear funciones y procedimientos de forma segura. Dado que las funciones PL se ejecutan dentro del servidor de la base de datos, el flag TRUSTED solo debe asignarse a lenguajes que no permitan el acceso a los componentes internos del servidor de la base de datos ni al sistema de archivos. Los lenguajes PL/pgSQL, PL/Tcl y PL/Perl se consideran de confianza; los lenguajes PL/TclU, PL/PerlU y PL/PythonU están diseñados para proporcionar una funcionalidad ilimitada y no deberían marcarse como de confianza.

En la sección Example 40.1 se muestra cómo funcionaría el procedimiento de instalación manual con el lenguaje PL/Perl.

Example 40.1. Instalación manual de PL/Perl

El siguiente comando le indica al servidor de la base de datos dónde encontrar el objeto compartido para la función del manejador de llamadas del lenguaje PL/Perl:

CREATE FUNCTION plperl_call_handler() RETURNS language_handler AS
    '$libdir/plperl' LANGUAGE C;

PL/Perl tiene una función de manejador en línea y una función de validación, por lo que también las declaramos:

CREATE FUNCTION plperl_inline_handler(internal) RETURNS void AS
    '$libdir/plperl' LANGUAGE C STRICT;

CREATE FUNCTION plperl_validator(oid) RETURNS void AS
    '$libdir/plperl' LANGUAGE C STRICT;

El comando:

CREATE TRUSTED LANGUAGE plperl
    HANDLER plperl_call_handler
    INLINE plperl_inline_handler
    VALIDATOR plperl_validator;

define entonces que las funciones declaradas previamente deben invocarse para las funciones y procedimientos donde el atributo de lenguaje sea plperl.

En una instalación por defecto de PostgreSQL, el manejador para el lenguaje PL/pgSQL se construye e instala en el directorio de “bibliotecas” (library); además, el lenguaje PL/pgSQL en sí se instala en todas las bases de datos. Si se configura el soporte para Tcl, los manejadores para PL/Tcl y PL/TclU se construyen e instalan en el directorio de bibliotecas, pero el lenguaje en sí no se instala en ninguna base de datos por defecto. Del mismo modo, los manejadores para PL/Perl y PL/PerlU se construyen e instalan si se configura el soporte para Perl, y el manejador para PL/PythonU se instala si se configura el soporte para Python, pero estos lenguajes no se instalan por defecto.