Después de crear y registrar una función definida por el usuario, el trabajo está prácticamente terminado.Postgres, sim embargo debe cargar el fichero de código objeto (e.g., a .o, o una biblioteca compartida) que implemente esa funcuín. Como se ha mencionado anteriormente, Postgres carga el código en tiempo de ejecución, a medida que es necesario. A fin de permitir que el código sea cargado dinámicamente, puede tener que compilar y enlazar este código de algún modo especial. esta sección explica brevemente como realizar la compilación y el enlazado necesario antes de que pueda cargar sus funciones en un servidor Postgres en ejecución. Nótese que este proceso ha cambiado respecto al de la versión 4.2.
Debe estar preparado para leer (y releer, y re-releer) las páginas de manual del compilador de C, cc(1), y del enlazador, ld(1), por si necesita información específica. Además, los paquetes de prueba de regresión del directorio PGROOT/src/regress contienen varios ejemplos de estwe proceso. Si comprende lo que realizan estas pruebas, no debería tener ningún problema.
La siguiente terminología se usará más adelante:
Carga dinámica (Dynamic loading) el lo que Postgres hace con un fichero objeto. El fichero objeto se copia en el servidor Postgres en ejecución, y las funciones y variables del fichero quedan disponibles para las funciones de los procesos Postgres. Postgres hace ésto usando el mecanismo de carga dinámica proporcionado por el sistema operativo.
Configuracion de la carga y enlazado (Loading and link editing) es lo que usted hace con un fichero objeto a fin de producir otro tipo de fichero objeto (por ejemplo, un programa ejecutable o una biblioteca compartida). Esto se realiza por medio del programa de configuración de enlazado, ld(1).
Las siguientes restricciones generales y notas se aplican también al texto siguiente:
Las rutas dadas a la orden para crear la función deben ser absolutas (es decir, han de empezar con "/"), y referirse a directorios visibles para la máquina en la que se está ejecutando el servidor Postgres.
Sugerencia: Las rutas relativas tambien funcionan, pero hay que terner en cuenta que serían relativas al directorio donde reside la base de datos (que es generalmente invisible para las aplicaciones finales). Obviamente, no tiene sentido hacer la ruta relativa al directorio en el que el usuario inicial la aplicacion final, dado que el servidor puede estar ejecutándose en una máquina distinta.
El usuario Postgres debe ser capaz de recorrer la ruta dada a la orden de creación de la función, y ser capaz de leer el fichero objeto. Esto es así porque el servidor Postgres se ejecuta como usuario Postgres, no como el usuario que inicia el proceso final. (Hacer el fichero el el directorio de nivel superior no leible y/o no ejecutable para el usuario "postgres" es un error extremadamente común.)
Los nombre de simbolos definidos en los fichero objetos no deben estar en conflicto entre sí, ni con los simbolos definidos en Postgres .
El compilador de C GNU normalmente no dispone de las opciones especiales necesarias para usar la interfase del cargador dinámico del systema. En caso de que esto ocurra, ha de usarse el compilador de C que venga con el sistema operativo.
Es muy facil escribir ficheros objeto de carga dinámica bajo ULTRIX. ULTRIX no tiene ningún mecanismo para bibliotecas compartidas, y por lo tanto, no plantea restricciones a la interfase del cargador dinámico. Por otra parte, tendremos que (re)escribir un cargador dinámico no portable, y no podremos usar verdaderas bibliotecas compartidas. Bajo ULTRIX, la unica restriccion es que debe producir cada fichero objeto con la opcion -G 0. (Nótese que es trata del número 0, no del literal "o"). Por ejemplo:
# simple ULTRIX example
% cc -G 0 -c foo.c
produce un fichero objeto llamado foo.o que puede ser cargado dinámicamente en Postgres .
No ha de realizarse carga o enlazado adicional.