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.
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 |