Guía para La Personalización de PostgreSQL 8.4

Guía para la personalización de
PostgreSQL 8.4
Personalización con funcionalidades de análisis de datos, monitoreo, administración,

desarrollo o seguridad
Centro de Tecnologías de Gestión de Datos (DATEC)
Universidad de las Ciencias Informáticas. Ciudad de La Habana, Cuba.
Aldo Cristiá Alvarez, Yeni Morgado Sánchez, Ing. Marcos Luis Ortíz Valmaseda,
Ing. Yudisney Vazquez Ortíz
Junio de 2010
Tabla de contenidos
Prefacio........................................................................................................................... 3
Audiencia .................................................................................................................... 3
Convenciones ............................................................................................................. 3
Secciones de la Guía .................................................................................................. 4
Requerimientos para ejecutar la Guía ........................................................................ 4
1.- Descripción del sistema de gestión de bases de datos PostgreSQL ........................ 6
1.1.- Definición de PostgreSQL ................................................................................... 6
1.2.- Funcionalidades de PostgreSQL ........................................................................ 6
1.3.- PostgreSQL 8.4 .................................................................................................. 7
2.- Procedimiento para la instalación y configuración del paquete PostgreSQL 8.4.1

desde el código fuente.................................................................................................... 8
3.- Descripción detallada de los módulos del contrib ................................................... 23
3.1.- Descripción de los módulos de análisis de datos ............................................. 23
3.2.- Descripción de los módulos de monitoreo ........................................................ 27
3.3.- Descripción de los módulos de administración ................................................. 29
3.4.- Descripción de los módulos de desarrollo ........................................................ 37
3.5.- Descripción de los módulos de seguridad ........................................................ 51
4.- Procedimiento para la compilación de los módulos del contrib de PostgreSQL 8.4 54
5.- Procedimiento para la compilación del módulo PL/R .............................................. 57
6.- Recomendaciones y buenas prácticas para la personalización de PostgreSQL .... 61
6.1.- Gestión de dependencias ................................................................................. 61
6.2.- Buena organización de los paquetes ................................................................ 62
6.3.- Desarrollo de scripts personalizados para la compilación de PostgreSQL ...... 62
7.- Procedimiento para la eliminación de los módulos ................................................. 71
2
Prefacio
Bienvenido a la Guía para la personalización de PostgreSQL 8.4, la cual está dirigida a

cualquier administrador de bases de datos que desee agregar a su sistema de gestión
de bases de datos PostgreSQL 8.4 funcionalidades de análisis de datos, monitoreo,
administración, desarrollo o seguridad.
Este prefacio contiene:
- Audiencia.
- Convenciones.
- Secciones de la Guía.
- Requerimientos para ejecutar la Guía.
Audiencia
La Guía para la personalización de PostgreSQL 8.4 difunde el conocimiento para la

asimilación del sistema de gestión de bases de datos PostgreSQL 8.4. La información
contenida en la Guía es aplicable al sistema operativo Debian GNU/Linux Lenny 5.0.
Esta guía está orientada a:
- Administradores de bases de datos PostgreSQL que deseen adquirir

habilidades para la compilación de módulos en el directorio contrib del Gestor.
- Administradores de bases de datos PostgreSQL que necesiten incorporar

nuevas funcionalidades al Gestor en lo referente al análisis de datos, el
monitoreo, la administración, el desarrollo o la seguridad.
Convenciones
Las siguientes convenciones de texto serán usadas en este documento:
Tabla 1.- Convenciones a utilizar durante la Guía
Convención Significado
Cambria, 11 pto, negrita Indica los comandos que se deben escribir en el terminal
de Debian, directorios o cualquier referencia a comandos y
extensiones dentro del texto.
Cambria, 11 pto, itálica Indica los comentarios a los comandos, para que puedan
ser entendidos.
3
Secciones de la Guía
La Guía tiene las siguientes secciones:
- Sistema de gestión de bases de datos PostgreSQL.
- Procedimiento para la instalación y configuración del paquete PostgreSQL

8.4.1 desde el código fuente.
- Descripción detallada de los módulos del contrib.
- Procedimiento para la compilación de los módulos del contrib de PostgreSQL

8.4.
- Procedimiento para la compilación del módulo PL/R.
- Recomendaciones y buenas prácticas para la personalización de PostgreSQL

8.4.
- Procedimiento para la eliminación de un módulo.
Requerimientos para ejecutar la Guía
Para ejecutar satisfactoriamente la Guía deben cumplirse los siguientes

requerimientos:
- Contar con el código fuente del PostgreSQL 8.4.
- Tener privilegios administrativos en el terminal donde serán ejecutados los

pasos.
- Estar conectado a los repositorios para la descarga efectiva de los paquetes

necesarios.
- Tener instalados los paquetes:
 GNU make (make): recomendado en su versión 3.76.1 o superior.
 tar, gzip: para descompactar las fuentes.
 Compilador ISO/ANSI C: GCC en este caso, seleccionado como

resultado del estudio realizado en el capítulo 1.
 zlib: librería de propósito general para la compresión y descompresión

de datos.
4
 GNU readline: librería usada por defecto, permite al psql1 recordar cada
línea de comando escrita y usar las teclas de cursor para volver a
mostrar y editar comandos previamente escritos.
- Tener 65 Mb de espacio en disco para el árbol de código durante la

compilación, 15 Mb para el directorio de la instalación y 25 Mb para el clúster
inicialmente vacío.
1
Intérprete de línea de comandos SQL de PostgreSQL.
5
1.- Descripción del sistema de gestión de bases de datos PostgreSQL
1.1.- Definición de PostgreSQL
PostgreSQL es un potente sistema de gestión de bases de datos objeto-relacional (O-

RDBMS), multiusuario, centralizado y de propósito general, que está siendo
desarrollado desde 1977 y está liberado bajo la licencia Berkeley Software Distribution
(BSD). Es ampliamente considerado como el sistema gestor de bases de datos de
código abierto más avanzado del mundo. Fue pionero en muchos conceptos que
estuvieron disponibles en algunos sistemas de bases de datos comerciales de alto
calibre, como por ejemplo: control de concurrencia multiversión, gestión de
transacciones y puntos de salvas. Fue uno de los primeros intentos en implementar un
motor de bases de datos relacional.
1.2.- Funcionalidades de PostgreSQL
Es el gestor de bases de datos de código abierto más avanzado actualmente, ofrece

sofisticadas características como:
- Organiza los datos mediante un modelo objeto-relacional.
- Capaz de manejar procedimientos, rutinas complejas y reglas.
- Soporta tablespaces2, transacciones anidadas, copias de seguridad en línea y

soporte para parte de los estándares SQL 92, 99, 2003 y 2008.
- Cuenta con una API sumamente flexible propia para el trabajo con varios
lenguajes de programación y procedurales como C, C++, .NET, Bash, Delphi,
PL/Java, PL/Perl, PL/Tcl, PL/pgSQL, PL/Ruby, PL/PHP, PL/Python,
PL/Scheme y PL/R.
- Ofrece transacciones que permiten el paso entre dos estados consistentes

manteniendo la integridad de los datos.
- Es altamente extensible, soporta operadores, funciones, métodos de acceso y

tipos de datos declarados por el usuario; soporta además sobrecarga de
operadores, sobrecarga de procedimientos, vistas materializables,
particionamiento de tablas y datos.
- Soporta integridad referencial, la cual es utilizada para garantizar la validez de

la información dentro de la base de datos.
2
Elemento que se utiliza para el almacenamiento de objetos temporales y para la organización física de
los objetos.
6
- Ofrece un control de acceso simultáneo a través de la gestión de múltiples
versiones de un mismo registro (MVCC).
- Las restricciones y disparadores tienen la función de mantener la integridad y

consistencia en las bases de datos.
- Usa una arquitectura cliente/servidor basada en un proceso por usuario. Existe

un proceso maestro que se ramifica para proporcionar conexiones adicionales
por cada cliente que se intenta conectar a PostgreSQL.
- Tiene incorporado el mecanismo Write Ahead Logging (WAL), que incrementa

la confiabilidad de las bases de datos al registrar los cambios antes de ser
escritos al disco; lo que asegura que, en caso de ocurrir un fallo crítico en las
bases de datos, exista un registro de transacciones del cual se pueda
restaurar.
1.3.- PostgreSQL 8.4
El Grupo Global de Desarrollo de PostgreSQL el 1 de julio del 2009 liberó la versión

8.4. Esta versión cuenta con una gran cantidad de funcionalidades y mejoras que se le
incorporaron para la administración, consultas y programación de PostgreSQL en aras
de incrementar su rendimiento.
La mayoría de los nuevos cambios con los que cuenta PostgreSQL 8.4 son
herramientas incorporadas, órdenes de administración y monitoreo. Entre las mejoras
más significativas que se le añadieron están:
- Restauración de bases de datos en procesos paralelos, que acelera la

recuperación de un respaldo hasta 8 veces mayor3.
- Nuevos métodos del ejecutor para anti joins y semijoins (EXISTS y NOT
EXISTS).
- Privilegios por columna, que permiten un control más granular de datos

confidenciales.
- Soporte mejorado para el Krb5, GSSAPI, SSPI.
- Reducción de la memoria en el manejo de los disparadores.
- Configuración de lenguajes por bases de datos, lo cual hace a PostgreSQL

más útil en entornos con múltiples idiomas.
3
La recomendación es tener un número de jobs en dependencia de la cantidad de procesadores de la
computadora.
7
- Actualizaciones desde 8.3 a 8.4 con muy bajo tiempo de inactividad, gracias al
uso de pg-migrator beta.
- Nuevas herramientas para monitoreo de consultas, que le otorgan a los

administradores mayor información sobre la actividad del sistema.
- Reducción de carga por el VACUUM, ampliamente reducida gracias al mapa de

visibilidad.
- Mejoras en la implementación en los índices hash.
- Nueva implementación del mapa de espacio libre para el uso de espacio físico
en disco y no en memoria.
- Nuevas implementaciones de los módulos del contrib: auto_explain,

pg_stat_statements, citext, btree_gin y pgbench.
- Consultas recursivas (WITH RECURSIVE).
- Inclusión de las CTE (Common Table Expression) (Consultas WITH).
- Mejoras en el manejo de los certificados SSL.
- Inclusión de funciones ventanas (OVER (PARTITION)).
- LIMIT puede estar basado en una subconsulta.
- Nuevo control de estructuras con la cláusula CASE.
- Soporta argumentos variables en funciones.
- Soporta argumentos por defecto en funciones.
La versión 8.4 hace el análisis de datos mucho más sencillo a través de

funcionalidades avanzadas de ANSI SQL 2003, las funciones ventanas, expresiones
comunes de tabla y consultas recursivas; estas estructuras de consulta aumentan
sustancialmente la expresividad del lenguaje SQL de PostgreSQL, permitiendo a los
usuarios realizar preguntas interesantes en una sola consulta.
2.- Procedimiento para la instalación y configuración del paquete PostgreSQL

8.4.1 desde el código fuente
En el alcance de la Guía no está contar con el paquete PostgreSQL en binario, por lo

que se hace necesario que la Guía para la personalización de PostgreSQL 8.4 tenga
una sección que sea para la instalación y configuración del mismo desde el código
fuente.
Los pasos para instalar PostgreSQL 8.4.1 desde el código fuente son los siguientes:
8
Paso 1.- Instalar make, tar y gzip, para satisfacer los tres primeros requerimientos de
los paquetes (generalmente estos son instalados por defecto cuando se instala el
sistema operativo, pero para estar seguros, se ejecuta este paso); para ello se utilizará
el gestor de paquetes apt4 con el comando siguiente:
# make, herramienta para el mantenimiento de grupos de programas, determina

automáticamente cuáles piezas de un programa necesitan ser recompiladas y
formula los comandos para ello.
# tar, programa de archivamiento para almacenar y extraer archivos de uno

conocido, como tarfile; su primer argumento debe ser una de las opciones A-c-d-r-t-u-
x, seguida por alguna función opcional, el último argumento son los nombres de los
archivos o directorios que deben ser archivados.
# gzip, compresor de archivos con extensión .gz.
apt-get install make tar gzip
Figura 1.- Ejecución de la instalación de make, tar y gzip
4
Advanced Package Tool, sistema de gestión para paquetes de software. El apt-get es una herramienta
de línea de comandos para el manejo de paquetes, puede ser considerada como la herramienta de
respaldo a otras que usan la librería apt.
9
Paso 2.- Instalar la herramienta build-essential, para satisfacer el requerimiento del
compilador; puede hacerse con el comando siguiente:
# build-essential contiene una lista informativa de los paquetes considerados

esenciales para la creación de paquetes Debian; facilita la instalación de cualquier
paquete que se especifique como dependencia del paquete sobre el que se esté
trabajando e incluye la instalación de GCC.
apt-get install build-essential
Figura 2.- Ejecución de la instalación de la herramienta build-essential
Paso 3.- Instalar las dependencias que necesita el PostgreSQL para su correcto
funcionamiento.
10
# libncurses, librería que provee una API al programador para escribir interfaces
basadas en texto; optimiza el refrescamiento de la pantalla, reduciendo la latencia
cuando se usan intérpretes de comandos remotos.
# libreadline, librería que provee un conjunto de funciones, usadas por las

aplicaciones, que permite a los usuarios editar las líneas de comando que escriben,
llamarlas de nuevo y reeditarlas.
# zlib, librería de propósito general de compresión de datos; provee funciones de

compresión y descompresión, incluyendo chequeos de integridad para los datos
descomprimidos.
apt-get install libncurses5-dev libreadline5-dev zlib1g-dev
Figura 3.- Ejecución de la instalación de las librerías libncurses5, libreadline5 y zlib1g
Paso 4.- Copiar el código fuente del gestor en el directorio usr/local/src.
11
# Por ejemplo si la ubicación de la fuente de PostgreSQL fuera el Escritorio de
administrador el comando sería cp –r /home/administrador/Escritorio/postgresql-
8.4.1.tar.gz /usr/local/src.
cp -r [ubicación_paquete] usr/local/src
Paso 5.- Ubicar el directorio desde donde se ejecutarán los comandos del terminal en
src, que será donde se instalará el PostgreSQL; para ello se debe utilizar el comando
siguiente:
# cd (change directory), cambia el directorio actual a la dirección especificada.
cd /usr/local/src/
Paso 6.- Descompactar el paquete PostgreSQL 8.4.1, puede hacerse con el comando
siguiente:
# La opción xvvzf permite extraer archivos .gz compactados.
tar xvzf PostgreSQL-8.4.1.tar.gz
PostgreSQL-8.4.1, paquete descompactado en el paso anterior; para ello puede
emplearse el comando:
# cd, cambia el directorio actual a la dirección especificada.
cd /usr/local/src/PostgreSQL-8.4.1/
Paso 8.- Proceder a la instalación del gestor, para ello escribir los comandos
siguientes:
# Para configurar las fuentes e indicar al instalador dónde crear los directorio de
instalación. ./configure es un sript que ejecutará un conjunto de pruebas para
determinar el valor de varias variables dependientes del sistema y detectar cualquier
cosa extraña del sistema operativo; crea varios archivos en el árbol de construcción
para guardar lo que encontró. Todos los archivos serán instalados en
/usr/local/pgsql por defecto. La opción --prefix especifica que todos los archivos
serán instalados en subdirectorios dentro del directorio especificado
(/usr/local/pgsql). Las opciones --without-pam --without-ldap --without-krb5
especifican que será instalado el sistema sin soporte a PAM (Pluggable
12
Authentication Modules), LDAP para la autenticación y conexión y Kerberos 5 para la
autenticación. La opción --enable-thread-safety permite hilos concurrentes en libpq
para el control seguro en el manejo de conexiones privadas.
# En caso de no tener permisos para la configuración del Gestor utilizar el comando

chmod +x configure para darle los permisos.
./configure --prefix=/usr/local/pgsql --without-pam --without-ldap --

without-krb5 --enable-thread-safety
Figura 4.- Ejecución del comando para la configuración de la fuente
# Comienza la construcción del árbol de código. La última línea de comando

mostrada al terminar su ejecución debe ser “All PostgreSQL is successfully made.
Ready to install”.
13
make
Figura 5.- Ejecución del comando make
# Instala todos los programas que conforman al PostgreSQL en pgsql (directorio

especificado en ./configure).
make install
14
Figura 6.- Ejecución del comando make install
# Elimina los archivos creados durante la instalación y que ya no serán necesarios.
make clean
15
Figura 7.- Ejecución del comando make clean
Una vez instalado el gestor, se deben realizar una serie de pasos para su
configuración.
Paso 1.- Crear usuario del sistema, a través del siguiente comando:
# El usuario del sistema será el dueño del sistema de ficheros generados por el gestor
y el encargado de ejecutar el motor de bases de datos. La herramienta adduser es
para añadir usuarios o grupos al sistema en /etc/adduser.conf, la opción --system
añade el usuario y el grupo al sistema, --quiet elimina mensajes informacionales, sólo
mostrando advertencias y errores, --home /var/lib/pgsql especifica que pgsql será el
directorio raíz del usuario, --shell /bin/bash especifica que se utilizará el directorio
dado como intérprete de autenticación de usuarios, --gecos “PostgreSQL
administrator” postgres cambia el campo gecos para la entrada especificada. El
16
usuario ha sido creado sin clave de acceso, por lo que la única forma de convertirse
en él, es siendo root.
adduser --system --quiet --home /var/lib/pgsql --shell /bin/bash --group -

-gecos "PostgreSQL administrator" postgres
Figura 8.- Ejecución del comando para crear el usuario del sistema
Paso 2.- Cambiar el usuario actual al usuario del sistema creado en el paso anterior,
para ello puede escribir el siguiente comando:
# su, comando usado para convertirse en otro usuario durante una sesión registrada
en el terminal. En este caso es utilizado para cambiar al usuario postgres.
su - postgres
Paso 3.- Crear el clúster de bases de datos, a través del siguiente comando:
/usr/local/pgsql/bin/initdb -D /var/lib/pgsql/data
17
Figura 9.- Ejecución del comando para crear el clúster de la base de datos
Paso 4.- Crear el directorio para los logs, necesario porque en caso de no hacerlo se
guardarían los logs del gestor dentro de la carpeta donde está instalado, ocupando
mucho espacio. Para ello se deben ejecutar los siguientes comandos:
# Desconectarse como postgres.
exit
# Crear el directorio donde se almacenarán los logs, mkdir crea un nuevo directorio
en la dirección especificada.
mkdir /var/log/pgsql/
# chown, cambia la propiedad de un usuario y/o grupos de los archivos dados.

Cambia el propietario de pgsql a grupo.usuario postgres.
18
chown postgres.postgres /var/log/pgsql
Paso 5.- Crear script de inicio con el siguiente contenido.
# cat, concatena el archivo que se hará al existente en /etc/init.d/postgresql en caso

de existir. Especifica que el servicio postgresql se iniciará cuando inicie el sistema y
especifica las opciones que tendrá el servicio de inicio, parada y reinicio.
19
cat > /etc/init.d/PostgreSQL << _EOF_
#!/bin/sh
case "\$1" in
start)
su - postgres -c "/usr/local/pgsql/bin/pg_ctl -
D /var/lib/pgsql/data -l
/var/log/pgsql/logfile.log start"
;;
stop)
/var/log/pgsql/logfile.log stop"
;;
restart)
/var/log/pgsql/logfile.log restart"
;;
*)
echo "Usage: \$0 {start|stop|restart}"
;;
esac
exit 0
_EOF_
20
Figura 10.- Ejecución del comando para crear el script de inicio
Paso 6.- Iniciar el sistema.
# chmod, cambia los permisos sobre el archivo especificado, en este caso da permisos
de lectura y ejecución al PostgreSQL para cualquiera y además permiso de escritura
para el propietario del fichero.
chmod 755 /etc/init.d/PostgreSQL
# Inicia el sistema PostgreSQL. Los números que aparecen, indican el orden en que se
va a iniciar y detener el dominio de PostgreSQL cuando inicie y se apague el servidor.
update-rc.d PostgreSQL defaults 99 01
21
Figura 11.- Ejecución del comando para iniciar el sistema
Paso 8.- Iniciar PostgreSQL, para ello se pueden emplear los comandos siguientes:
/etc/init.d/PostgreSQL start
Paso 9.- Editar el fichero /etc/profile para que el gestor pueda ser encontrado por los
programas.
# Abre el fichero profile, donde se encuentran las variables de entorno del sistema,
conjunto de valores dinámicos que normalmente afectan el comportamiento de los
procesos en la computadora.
nano /etc/profile
# Añadir la línea al final del fichero, antes de la línea export PATH. PATH es una
variable de entorno donde se indican los caminos a los ejecutables del sistema (los
comandos). Por ejemplo cuando se pone en el terminal el comando “nano”, el sistema
busca en los diferentes caminos que están definidos en la variable PATH para
completar la ruta al fichero, que realmente es “/usr/bin/nano”. Cuando se pone en el
terminal un comando y el camino para llegar a él no está en el PATH, el sistema da
un error. EL siguiente comando añade el camino a los comandos de PostgreSQL en el
PATH, para poder ejecutar por ejemplo “psql” sin tener que poner
“/usr/local/pgsql/bin/psql”.
PATH=/usr/local/pgsql/bin:$PATH
22
Figura 12.- Ejecución del fichero donde se encuentran las variables de entorno del sistema
3.- Descripción detallada de los módulos del contrib
Para la descripción de los módulos se utilizará una plantilla definida con los elementos
que, a partir del estudio realizado, son difíciles de encontrar y son necesarios para la
selección de qué módulo utilizar según las necesidades del proyecto.
3.1.- Descripción de los módulos de análisis de datos

Tabla 2.- Descripción del módulo cube de análisis de datos (EnterpriseDB Corporation, 2010),
(PostgreSQL CVSweb, 2010), (PostgreSQL Global Development Group, 2010)
Elemento Descripción
Descripción Implementa un tipo de datos cube para la representación

de cubos multidimensionales.
A continuación se muestran las representaciones

externas válidas para el tipo de datos cube:
- x y (x): punto de dimensiones o longitud cero de una
23
dimensión de intervalo.
- x1, x2,..., xn y (x1, x2,..., xn): punto en el espacio

dimensional n, representado internamente como un
cubo de volumen cero.
- (x), (y) y [(x), (y)]: dimensión de intervalos iniciada

en x y terminada en y, o viceversa.
- (x1,..., xn), (y1,..., yn) y [(x1,..., xn), (y1,..., yn)]:

cubo con n dimensiones representado por un par de
esquinas diagonalmente opuestas.
Los valores son almacenados internamente como puntos

de números flotantes de 64 bits (los números con más
de 16 dígitos significativos, serán truncados).
Fecha de creación 11-12-2000
Lugar de origen Grupo Global de Desarrollo de PostgreSQL
Desarrolladores Gene Selkov, ha hecho contribuciones sobresalientes a

los campos de análisis matemático/computacional del
metabolismo celular, la cronobiología, la bioinformática y
la ingeniería metabólica, además contribuyó con
PostgreSQL añadiéndole en el contrib el módulo cube.
Lenguaje de desarrollo C
Fecha de última versión v 1.37, 11-06-2009
Soporte Grupo Global de Desarrollo de PostgreSQL
Grado de generalización Alto
Comandos para su Para instalar el módulo desde la distribución de la fuente

instalación5 del Gestor se debe realizar lo siguiente:
En la fuente principal de PostgreSQL existe una carpeta

llamada contrib, dentro de esta carpeta se encuentran
5
Los comandos y ubicación son los mismos para la mayoría de los módulos, de ahora en adelante se
prescindirá de estas filas en el resto de las descripciones, a no ser que sean diferentes.
24
otras con el nombre de cada módulo, para instalarlo
debe posicionarse en el terminal en la ubicación del
módulo y escribir los comandos siguientes:
make
make install
Muchos de los módulos cuentan con pruebas de

regresión, las cuales puede ser ejecutada con:
make installcheck
Ubicación Directorio contrib del paquete de instalación de

PostgreSQL 8.4.1.
Tabla 3.- Descripción del módulo fuzzystrmatch de análisis de datos (EnterpriseDB

Corporation, 2010), (PostgreSQL CVSweb, 2010), (PostgreSQL Global Development Group,
2010)
Descripción Proporciona varias funciones para determinar las

similitudes y la distancia entre las cadenas, brinda apoyo
para levenshtein/soundex/metaphone.
- Levenshtein: calcula la distancia levenshtein entre

dos cadenas.
levenshtein(text source, text target, int ins_cost,

int del_cost, int sub_cost) returns int
levenshtein(text source, text target) returns int
- Soundex: método para obtener los nombres que

coincidan y convertirlos en un mismo código. El
módulo fuzzystrmatch proporciona dos funciones
para trabajar con los códigos de Soundex:
soundex(text) returns text

difference(text, text) returns int
- Metaphone: esta función, como soundex, se basa

en la idea de construir un código de
representación de una cadena de entrada; dos
25
cadenas de la serie se considerarán similares si
tienen los mismos códigos.
Desarrolladores Bruce Momjian, se unió al proyecto en el año 1996,

proporcionó junto a otras personas el primer servidor de
desarrollo no universitario para el esfuerzo de desarrollo
de código abierto y comenzó a trabajar para estabilizar
el código de Postgres95.
Joe Conway, ha participado con PostgreSQL como

contribuyente desde el 2001. Su trabajo en el Grupo es
la implementación de funciones de tablas, mejoras en
tipos de datos array y byte, librerías del contrib, además
de otros ajustes y características realizadas para el
Gestor.
Tabla 4.- Descripción de PL/R de análisis de datos (bostongis.com, 2010)
Descripción Lenguaje procedural para PostgreSQL que permite

escribir funciones y contar con las funciones agregadas
del lenguaje de análisis estadísticos y gráficos R.
26
Desarrolladores Joe Conway6.
Fecha de última versión v plr-8.3.0.9 ,01-02-2010
Ubicación http://www.joeconway.com/plr/
3.2.- Descripción de los módulos de monitoreo

Tabla 5.- Descripción del módulo pg_buffercache de monitoreo (EnterpriseDB Corporation,
2010), (PostgreSQL CVSweb, 2010), (PostgreSQL Global Development Group, 2010)
Descripción Proporciona un medio para examinar lo que está

sucediendo en el búfer de caché en tiempo real.
El módulo ofrece una función pg_buffercache_pages

que retorna un conjunto de registros; además de una
vista pg_buffercache que devuelve la función para un
uso más cómodo.
Desarrolladores Mark Kirkwood, ha sido un usuario activo y miembro de

la comunidad de PostgreSQL, además ha contribuido
con varios módulos de código para el Grupo Global de
Desarrollo de PostgreSQL. Pasó varios años en Oracle,
trabajando como programador en las áreas de ajuste del
rendimiento y administración de bases de datos.
6
Ver en la Tabla 3 su breve reseña.
27
Tabla 6.- Descripción del módulo pg_freespacemap de monitoreo (EnterpriseDB Corporation,

Descripción Este módulo proporciona un método para examinar el

mapa de espacio libre.
Desarrolladores Mark Kirkwood.7
Heikki Linnakangas, lleva largo tiempo de desarrollador

de PostgreSQL, ha trabajado en muchas partes del
Gestor, en funcionalidades como realizar commit en dos
fases y el nuevo mapa de espacio libre en la
implementación de PostgreSQL 8.4.
Fecha de última versión v1.14, 11-06-2009
Grado de generalización Medio
Tabla 7.- Descripción del módulo pg_stat_statements de monitoreo (EnterpriseDB Corporation,

7
28
Descripción Proporciona un medio para el seguimiento de las
estadísticas de la ejecución de todas las sentencias
SQL ejecutadas por un servidor.
Desarrolladores Takahiro Itagaki, ingeniero de bases de datos en el

centro NTT OSS8, enfocado en el uso de PostgreSQL
en los servicios de misiones críticas desde el 2004.
Contribuyó en el refinamiento de los puntos de
comprobación, en el rendimiento de estabilización de las
funciones de PostgreSQL 8.3. Está trabajando en
características de alta disponibilidad y confiabilidad en
PostgreSQL y en transferencia de los sistemas de
legado a PostgreSQL.
3.3.- Descripción de los módulos de administración

Tabla 8.- Descripción del módulo adminpack de administración (EnterpriseDB Corporation,
Descripción Librería que provee funciones de soporte que pgAdmin o

cualquier otra herramienta de administración puede usar
para proveer funcionalidades adicionales, tales como:
- Muestra del tamaño en disco de los tablespaces, bases

de datos, tablas e índices en la pestaña de Estadísticas,
8
Firma de telefonía japonesa Nippon Telegraph and Telephone, software de código abierto.
29
en la ventana principal del pgAdmin.
- La ventana Estado del servidor, en la pestaña Estado,

muestra las conexiones actuales a cada base de datos,
los usuarios conectados, los ID de los procesos, las
direcciones de los clientes y el tiempo de comienzo
(desde PostgreSQL 8.1), la consulta actual que será
ejecutada y el tiempo de comienzo de la consulta (desde
PostgreSQL 7.4). Las consultas pueden cancelarse.
- Administración remota de los archivos de configuración

del servidor (postgresql.conf, pg_hba.conf).
Las funciones implementadas pueden ser ejecutadas

solamente por el superusuario.
Fecha de creación PostgreSQL 8.2 es la primera versión donde se incluye

al adminpack como módulo en el contrib, 30-05-2006
Lugar de origen Comunidad de desarrollo del pgAdmin
Desarrolladores Andreas Pflug, catalogado como uno de los 21 mayores

contribuidores al gestor PostgreSQL. Ha trabajado en el
subproceso syslog, integrado el dbsize en el backend,
mejorado la administración del lado del servidor y ha
hecho la mayoría del código del pgAdmin III, el cual
ayuda a mantener.
Fecha de última versión v1.12, 01-01-2009
Soporte Equipo de desarrollo del pgAdmin
Tabla 9.- Descripción del módulo oid2name de administración (EnterpriseDB Corporation,

30
Descripción Este módulo es una utilidad que ayuda a los
administradores a examinar la estructura de los archivos
utilizados por PostgreSQL.
Requiere de un servidor de base de datos ejecutándose

con los catálogos de sistemas no corruptos. Por tanto,
es de uso limitado para recuperarse de situaciones de
bases de datos de corrupción catastrófica.
Desarrolladores B. Palmer.
Tabla 10.- Descripción del módulo pgbench de administración (EnterpriseDB Corporation,

Descripción Es un programa sencillo para ejecutar las pruebas de

rendimiento sobre PostgreSQL. Es ejecutado en la
misma secuencia de los comandos SQL, posiblemente
en bases de datos de múltiples sesiones concurrentes y
después calcula la tasa promedio de operaciones
(operaciones por segundos).
Por defecto, un escenario de prueba pgbench es

aproximadamente basado en TPC-B, que implica los
comandos SELECT, UPDATE e INSERT.
Pgbench tiene soporte para el funcionamiento de

escenarios de referencia personalizado mediante la
31
sustitución de la secuencia de comandos
predeterminado de la transacción, con una secuencia de
comandos de transacción para leer de un archivo (-f
option), en este caso una transacción se considera
como una ejecución de un archivo de comandos. Incluso
se pueden especificar varias secuencias de comandos
(multiple -f options), en cuyo caso se escoge al azar y se
eligen las secuencias de comandos cada vez que se
inicia en la sesión de cliente una nueva transacción.
Desarrolladores Tatsuo Ishii, autor de pgPool, ha participado en

PostgreSQL desde 1996. Es co-fundador del Grupo de
Japón de usuario de PostgreSQL (JPUG). Ha escrito
muchos libros y artículos de PostgreSQL en Japón y
está trabajando para la compañía SRA OSS9, Inc. de
Japón, que ofrece diversos servicios relacionados con
PostgreSQL.
Tabla 11.- Descripción del módulo lo de administración (EnterpriseDB Corporation, 2010),

Descripción Proporciona soporte para la gestión de objetos grandes

(LOs o Large Objects), este incluye un tipo de datos lo y
9
Empresa dedicada principalmente a los productos de código abierto y tecnologías Linux, además de
ofrecer servicios de software japoneses.
32
un disparador lo_manage.
Permite además arreglos de éste por un disparador para

las tablas que contienen columnas de referencias lo
adjuntado. El disparador esencialmente lo que hace es
un lo_unlink cada vez que elimina o modifica un valor
referenciando a un objeto de gran tamaño; al utilizar
este disparador, se supone que sólo hay una referencia
de bases de datos a cualquier objeto grande que se
hace referencia en un disparador de columnas
controladas.
El módulo también proporciona un tipo de datos lo, que

es realmente sólo un dominio de tipo OID. Esto es útil
para diferenciar las columnas de las bases de datos que
contienen referencias a objetos grandes desde estos
que son OIDs de otros objetos.
No se tiene que utilizar el tipo de dato lo para usar el

disparador, pero puede ser conveniente usarlo para
hacer un seguimiento de las columnas que representan
objetos grandes en las bases de datos que se están
manejando con el disparador.
Desarrolladores Peter Mount.
33
Tabla 12.- Descripción del módulo pg_standby de administración (EnterpriseDB Corporation,
Descripción Este módulo apoya la creación de servidores suplentes

de bases de datos. Está diseñado para ser un programa
de producción listo, así como una plantilla personalizable
en caso de necesitar modificaciones específicas.
Está diseñado para ser un restore_command de espera,

que se necesita para convertir un archivo estándar de
recuperación en una operación de espera.
pg_standby incluye diversas características como:
- Portátil y fácil de instalar.
- Fácil para modificar el código fuente con

secciones especialmente diseñadas para
modificar sus propias necesidades.
- Ha sido probado en Linux y Windows.
El módulo pg_standby está diseñado para trabajar con

PostgreSQL 8.2 y versiones posteriores.
Desarrolladores Simon Riggs, arquitecto de bases de datos con 20 años

de experiencia profesional en el rendimiento de diseño
de bases de datos de importancia crítica, tanto para
OLTP como sistemas de almacenamiento de datos en
grandes empresas. Es un importante promotor del
proyecto PostgreSQL ya que ha contribuido con varias
características como punto de recuperación en el tiempo
(8.0), particionado (8.1), además del respaldo de bajo
impacto (8.2).
34
Tabla 13.- Descripción del módulo pgrowslocks de administración (EnterpriseDB Corporation,

Descripción Proporciona una función de bloqueo de registro para

mostrar información de una tabla especificada.
Desarrolladores Tatsuo Ishii.10
Tabla 14.- Descripción del módulo pgstattuple de administración (EnterpriseDB Corporation,

Descripción Proporciona diversas funciones para obtener

estadísticas a nivel de tupla.
10
35
Desarrolladores Tatsuo Ishii.9
Satoshi Nagayasu, en 2004 empezó a trabajar en

PostgreSQL como programador e ingeniero, al mismo
tiempo trabajaba como director de Grupo de Usuarios
de PostgreSQL de Japón (JPUG) y en proyecto y
ejecución de varios eventos de la Comunidad, tales
como JPUG conferencias, campamentos y grupos de
estudio. Se unió a varios grupos de proyectos de
PostgreSQL, incluyendo Slony-II.
Tabla 15.- Descripción del módulo pageinspect de administración (EnterpriseDB Corporation,

Descripción Proporciona funciones que permiten inspeccionar el

contenido de las páginas de bases de datos a un bajo
nivel, útil para propósitos de depuración. Todas estas
funciones solamente pueden ser usadas por
superusuarios.
Desarrolladores Heikki Linnakangas.11
11
36
3.4.- Descripción de los módulos de desarrollo

Tabla 16.- Descripción del módulo auto_explain de desarrollo (EnterpriseDB Corporation,
Descripción Proporciona un método para registrar automáticamente

los planes de lenta ejecución de las consultas, sin tener
que ejecutar EXPLAIN manualmente. Esto es
especialmente de gran utilidad para dar seguimiento a la
optimización de consultas en las aplicaciones de gran
tamaño.
El módulo no proporciona funciones de acceso SQL;

para usarlo, simplemente se carga en el servidor, se
puede cargar en una sesión individual LOAD
'auto_explain'.
Debe ser un superusuario para utilizarlo.
Existen varios parámetros de configuración que controlan

el comportamiento del módulo auto_explain. Se debe
tener en cuenta que el comportamiento por defecto es no
hacer nada, por lo que debe establecer al menos
auto_explain.log_min_duration si desea obtener
resultados, los cuales se mencionarán a continuación:
- auto_explain.log_min_duration (integer): es el
tiempo de ejecución mínimo de la instrucción, se
da en milisegundos, esta función hará que el plan
de la sentencia esté registrado.
- auto_explain.log_analyze (boolean): retorna los

resultados del cumplimiento del plan de ejecución,
además de analizar hace que la declaración sea
37
ejecutada realmente, no sólo planeada y, da las
salidas para ser mostradas cuando se registra un
plan de la ejecución. Este parámetro está
desactivado por defecto. Solamente los
superusuarios pueden cambiar esta configuración.
Desarrolladores Takahiro Itagaki.12
Tabla 17.- Descripción del módulo hstore de desarrollo (EnterpriseDB Corporation, 2010),
Descripción Implementa un tipo de dato hstore para almacenar un

conjunto de pares (clave, valor) dentro de un único
campo de dato en PostgreSQL. Esto puede ser útil en
diversos escenarios tales como las filas con muchos
atributos que rara vez son examinados o datos semi-
estructurados.
En la implementación común, ni el número ni la cadena

de valores pueden excederse de 65 535 bytes de
longitud, se produce un error si se supera este límite.
Estas longitudes máximas pueden cambiar en futuras
versiones.
12
38
Desarrolladores Oleg Bartunov, ha estado involucrado en el desarrollo de

PostgreSQL desde 1996. Junto a su colega Teodor
Sigaev desarrolló la infraestructura para la aplicación de
usuario como definir los métodos de acceder al índice de
GIST y GIN, integrados en su totalidad, las instalaciones
de búsqueda de texto en PostgreSQL 8.3 y una serie de
extensiones populares como intArray, ltree, hstore y
pg_trgm.
Teodor Sigaev, miembro del Grupo Global de Desarrollo

de PostgreSQL desde el 2000; sus principales
contribuciones son los índices GIN y GIST, además de
añadir varios módulos al contrib. Miembro activo de la
comunidad PostgreSQL rusa.
Fecha de última versión v 1.16 26-02-2010
Tabla 18.- Descripción del módulo ltree de desarrollo (EnterpriseDB Corporation,

Descripción Implementa un tipo de datos ltree para la representación

de las etiquetas de los datos almacenados en un árbol
de estructura jerárquica.
Con amplias facilidades para la búsqueda a través de la

etiqueta de árboles proporcionada. Una etiqueta es una
secuencia de caracteres alfanuméricos y guiones, que
deben ser de menos de 256 bytes de longitud.
39
El módulo ltree soporta diferentes tipos de datos como
son:
- ltree: almacena una ruta de la etiqueta.
- lquery: representa una expresión regular como el

patrón de valores coincidentes ltree.
- ltxtquery: representa un patrón de búsqueda de

textos completo para la comparación de valores
ltree; contiene palabras posiblemente con los
modificadores @, *, % al final; éstos tienen los
mismos significados como en lquery; las palabras
puede ser combinadas con & (AND), | (OR), !
(NOT) y paréntesis. La principal diferencia entre ella
y lquery es que compara palabras sin tener en
cuenta su posición en el camino de la etiqueta.
Desarrolladores Teodor Sigaev.13
Oleg Bartunov.14
Tabla 19.- Descripción del módulo pg_trgm de desarrollo (EnterpriseDB Corporation, 2010),
13
Ver en la Tabla 17 para su breve reseña.
14
40
Descripción El módulo de pg_trgm proporciona funciones y
operadores para determinar la similitud de texto basado
en la correspondencia trigrama, así como clases de
índices de operador que apoyan la búsqueda rápida por
cadenas similares.
Oleg Bartunov.16
Tabla 20.- Descripción del módulo seg de desarrollo (EnterpriseDB Corporation, 2010),
Descripción Implementa un tipo de dato seg para la representación

de segmentos de línea o intervalos de puntos flotante.
Puede representar la incertidumbre en las variables de
intervalo, lo que resulta especialmente útil para
representar las mediciones de laboratorio.
Los valores seg son almacenados internamente como

pares de números de 32 bits de punto flotante. Esto
significa que los números con más de 7 dígitos
significativos serán truncados.
15
16
41
Desarrolladores Gene Selkov.17
Tabla 21.- Descripción del módulo tablefunc de desarrollo (EnterpriseDB Corporation, 2010),
Descripción El módulo tablefunc incluye varias funciones que

retornan tablas. Estas funciones son útiles tanto en su
propio derecho como en ejemplos para escribir
funciones en C que retornen múltiples filas.
Desarrolladores Joe Conway.18
17
18
42
Tabla 22.- Descripción del módulo uuid-ossp de desarrollo (EnterpriseDB Corporation, 2010),
Descripción Proporciona funciones para generar identificadores

únicos universales (UUID) usando uno de varios
algoritmos estándares. También tiene funciones
especiales para producir ciertas constantes UUID.
Desarrolladores Peter Eisentraut.
Tabla 23.- Descripción del módulo citext de desarrollo (EnterpriseDB Corporation, 2010),
Descripción Proporciona un tipo de cadena de caracteres case-

insensitive; esencialmente convierte internamente a
minúsculas cuando compara valores.
Permite eliminar la conversión a minúsculas en las

consultas SQL y permite que las llaves primarias sean
case-insensitive.
Este comportamiento es idéntico a usar la conversión a

minúsculas en las consultas, pero es realizado de forma
transparente por el tipo de dato.
43
Desarrolladores David E. Wheeler, ha estado trabajando con

PostgreSQL hace más de 10 años, principalmente
desempeñándose como desarrollador y proveedor de
mantenimiento para la gestión de contenidos y sistema
de publicación de Bricolage19. Sus especialidades de
consultoría incluyen diseño de bases de datos,
implementación de aplicaciones, banco de datos de
pruebas, aplicación de programación de procedimientos
almacenados y además contribuye en el desarrollo de
módulos para el contrib de PostgreSQL.
Tabla 24.- Descripción del módulo dict_xsyn de desarrollo (EnterpriseDB Corporation, 2010),
Descripción Diccionario de sinónimos extendido, es un ejemplo de un

diccionario plantilla añadido para la búsqueda de texto
completo. Este tipo de diccionario sustituye palabras con
los grupos de sus sinónimos, haciendo posible la
búsqueda de una palabra con alguno de sus sinónimos.
Dict_xsyn acepta las siguientes opciones:
- Keeporig, controla si se incluye la palabra original (si

es cierto) o sólo sus sinónimos (si es falsa). El valor
predeterminado es cierto.
- Las reglas son los nombres bases del archivo que
19
Es un sistema de publicaciones Web, gestión de contenido de clase empresarial y de código abierto.
44
contiene la lista de sinónimos. Este archivo debe
estar almacenado en $SHAREDIR/tsearch_data/
donde $SHAREDIR mantiene la instalación de
PostgreSQL compartida en el directorio de datos.
Este nombre debe finalizar en .rules, las cuales no
deben ser incluidas en el parámetro de reglas.
Desarrolladores Sergey Karpov.
Tabla 25.- Descripción del módulo spi de desarrollo (EnterpriseDB Corporation, 2010),
Descripción Proporciona varios ejemplos viables para usar spi y

disparadores. Mientras que estas funciones son de algún
valor en su propio derecho, además son más útiles como
ejemplos para modificar sus propios fines. Las funciones
son suficientemente generales como para ser utilizadas
en cualquier tabla, pero se tienen que especificar los
nombres de las tablas y campos.
20
45
Oleg Bartunov.21
Tabla 26.- Descripción del módulo test_parser de desarrollo (EnterpriseDB Corporation, 2010),
Descripción Es un ejemplo de un analizador de encargo para la

búsqueda de texto completo. No hace nada
especialmente útil, pero puede servir como punto de
partida para el desarrollo de intérpretes propios.
Desarrolladores Sergey Karpov.22
Tabla 27.- Descripción del módulo btree_gin de desarrollo (EnterpriseDB Corporation, 2010),
21
22
46
Descripción Proporciona una muestra de una clase de operador GIN
que implementa el comportamiento equivalente de B-
Tree23 para los tipos de datos int2, int4, int8, float4,
float8, timestamp con/sin zona horaria, time con/sin
zona horaria, fecha, intervalo, oid, moneda, char,
varchar, text, bytea, bit, varbit, macaddr, inet y cidr.
En general, estas clases de operadores no superarán el

estándar equivalente de los métodos principales btree,
además carecen de características principales del
código btree estándar, la capacidad de cumplir la
unicidad.
Sin embargo, son útiles para las pruebas GIN y como

base para el desarrollo de las clases de otro operador
GIN. Además, para las consultas que ponen a prueba
las columnas indexables GIN y la columna indexable
btree, podría ser más eficiente crear múltiples columnas
de índice GIN, que usar uno de estos operadores de
clases para la creación de dos índices distintos que se
deben combinar a través de mapas de bits ANDing (tipo
de índice para encontrar identificadores de la relación)
Lugar de origen Grupo de Desarrollo Global de PostgreSQL
Oleg Bartunov.25
23
Estructuras de árbol que se encuentran comúnmente en las implementaciones de bases de datos y
sistemas de archivos.
24
25
47
Soporte Grupo de Desarrollo Global de PostgreSQL
Tabla 28.- Descripción del módulo btree_gist de desarrollo (EnterpriseDB Corporation, 2010),
Descripción Este módulo ofrece una muestra de clases de operador

GIST, que implementa un B-tree equivalente al
comportamiento para los tipos de datos int2, int4, int8,
float4, float8, numérico, fecha y hora con la zona horaria,
fecha y hora sin zona horaria, el tiempo con la zona
horaria, el tiempo sin zona horaria, fecha, intervalo, oid,
char, varchar, text, byte, bit, varbit, macaddr, inet y cidr.
En general, estas clases de operador no superan el nivel

equivalente a los métodos índice btree, y además
carecen de una de las principales características del
código btree estándar, la capacidad de hacer cumplir la
unicidad. Sin embargo, son útiles para las pruebas GIST
y como base para el desarrollo de las clases de otro
operador de GIST.
Lugar de origen Universidad de California en Berkeley GiST
Oleg Bartunov.27
Janko Richter, añadió soporte para marca de tiempo con

o sin zona horaria, fecha, intervalo, oid, el dinero y los
tipos de macaddr a btree_gist.
26
27
48
Tabla 29.- Descripción del módulo earthdistance de desarrollo (EnterpriseDB Corporation,

Descripción Este módulo ofrece dos enfoques diferentes para

calcular las distancias de gran círculo en la superficie
de la Tierra. El primero que se describe depende del
paquete de cubo (que debe estar instalado antes de
earthdistance). El segundo se basa en el tipo de datos
incorporado en el punto, usando la longitud y latitud de
las coordenadas.
En este módulo, se supone que la tierra es

perfectamente esférica.
Los datos se almacenan en cubos que son puntos

usando 3 coordenadas representado las distancias X,
Y, Z desde el centro de la Tierra. Un dominio earth
sobre cube es dado, que incluye restricciones de
control de que el valor cumple estas restricciones y es
razonablemente cercano a la superficie real de la
Tierra.
El radio de la Tierra se obtiene con la función earth() y

se da en metros. Para cambiar esta función se puede
cambiar el módulo para utilizar otras unidades, o para
utilizar un valor diferente del radio que se crea el más
apropiado.
Este paquete tiene aplicaciones para bases de datos

astronómicas. Los astrónomos probablemente pueden
cambiar la función earth() para devolver un radio de
49
180/pi de modo que las distancias sean en grados.
Las funciones son proporcionadas para apoyar la

entrada en latitud y longitud (en grados), la producción
de latitud y longitud, para calcular la distancia circular
entre dos puntos y especificar fácilmente un rectángulo
que pueda emplearse para búsquedas de índices.
Desarrolladores Bruno Wolff III.
Hal Snyder.

PostgreSQL 8.4.1.
Tabla 30.- Descripción del módulo isn de desarrollo (EnterpriseDB Corporation, 2010),
Descripción Proporciona un tipo de datos isn para el producto

internacional de numeración estándar siguiente:
EAN13, UPC, ISBN (books), ISMN (music) y ISSN
(serials). Los números son validados a la entrada y se
produce una salida correcta.
Proporciona un operador de comparación estándar,

además de indexaciones btree y hash, para todos esos
tipos de datos.
50
Desarrolladores Germán Méndez Bravo.

PostgreSQL 8.4.1.
3.5.- Descripción de los módulos de seguridad

Tabla 31.- Descripción del módulo chkpass de seguridad (EnterpriseDB Corporation, 2010),
Descripción Implementa un tipo de datos chkpass que está diseñado

para almacenar contraseñas encriptadas. Cada
contraseña se convierte automáticamente en forma
cifrada a la entrada y siempre se almacena cifrada. Para
comparar, basta comparar contra una contraseña en
texto claro y la función de comparación se cifran antes
de comparar.
Hay provisiones en el código para reportar un error si se

determina que la contraseña es fácilmente manipulada.
- Si se empieza una cadena de entrada con dos

puntos (:), se asume que esta es la contraseña de
cifrado y es almacenada sin un cifrado adicional.
- Si en la salida se anteponen dos puntos (:), esto

hace posible desechar o recargar las contraseñas
sin volver a cifrarlas. Si se desea la contraseña sin
51
los dos puntos (:) entonces se utiliza la función raw
(), esta función permite que se utilice el módulo tipo
Apache's Auth_PostgreSQL.
Desarrolladores D'Arcy J.M. Cain, actualmente es el co-propietario de

Vex Consulting Incorporated, una compañía de
desarrollo ágil de software. Está involucrado con el
NetBSD28, con proyectos de PostgreSQL y es el
responsable principal de PyGreSQL, una interfaz de
Python para PostgreSQL. Además, ha escrito muchos
programas y distribuciones bajo una licencia de código
abierto.
Tabla 32.- Descripción del módulo pgcrypto de seguridad (EnterpriseDB Corporation, 2010),
Descripción Proporciona funciones criptográficas para PostgreSQL.

Contiene diversas funciones generales hash, las cuales
son:
- digest (): calcula un valor hash binario de los

datos dados. Los algoritmos estándares son
MD5, SHA1, sha224, SHA256, SHA384 y
28
Es un proyecto rápido, seguro, está disponible para una amplia gama de plataformas y el código fuente
está disponible libremente bajo una licencia de actividad empresarial.
52
SHA512, si pgcrypto está construido con
OpenSSL.
- hmac (): calcula el hash MAC de los datos con la

tecla clave. Esto es similar a digest (), pero el
hash sólo se puede calcular conociendo la clave.
Esto evita que alguien altere los datos y que
además se cambie el hash con el que coincide
los mismos. Si la clave es mayor que el tamaño
de bloque de hash, primero será hash y el
resultado se utilizará como clave.
Desarrolladores Marko Kreen, es ingeniero de software en la compañía

Skype, con énfasis en las herramientas de base de
datos. Ha estado utilizando PostgreSQL alrededor de 8
años. Una de sus primeras contribuciones a PostgreSQL
fue añadir pgcrypto al contrib y además sigue trabajando
en este.
Tabla 33.- Descripción del módulo veil de seguridad (doxygen, 2010), (pgfoundry.org, 2010)
Descripción Es una inclusión de seguridad de datos para

PostgreSQL. Proporciona una API que permite controlar
el acceso a los datos de la fila, columna e incluso de
nivel. Los diferentes usuarios podrán ejecutar la misma
consulta y ver los resultados diferentes. Otros
53
proveedores de bases de datos describen esto como
una base de datos virtual privada.
Si se tiene una aplicación de bases de datos de reserva

que almacena datos sensibles, se puede tomar por lo
menos algunas medidas para proteger esos datos. Veil
proporciona una manera de proteger sus datos con un
mecanismo de seguridad dentro de la propia base de
datos. Sólo puede cambiar veil si se tiene privilegios de
superusuario.
Desarrolladores Marc Munro, es consultor de bases de datos basado en

Vancouver especializado en el diseño y arquitectura de
bases de datos. Defensor del software libre,
particularmente de PostgreSQL.
Lenguaje de desarrollo C, PL/pgSQL
Fecha de última versión v.0.9.11 (Beta), 12-03-2010
Ubicación http://pgfoundry.org/frs/?group_id=1000139&release_id=
1597
4.- Procedimiento para la compilación de los módulos del contrib de PostgreSQL

8.4
Antes de compilar cualquier módulo es necesario realizar los pasos 1 y 2, que serán
hechos sólo una vez aun cuando se quieran compilar tantos módulos como se deseen
e incluso cuando dicha compilación no sea realizada en el mismo momento.
Paso 1.- Compilar el directorio port para que sean incluidas librerías necesarias para la
ejecución de los módulos, para ello se pueden emplear los comandos siguientes:
# cd, cambia el directorio para port, a quien se le realizará la compilación.
54
cd /usr/local/src/postgresql-8.4.1/src/port
# Primer paso del proceso de compilación.
make
# Segundo paso del proceso de compilación.
make install
Paso 2.- Compilar los directorios interfaces para que sean incluidas librerías
necesarias para la ejecución de los módulos, para ello se pueden emplear los
comandos siguientes:
# cd, cambia el directorio para interfaces, a quien se le realizará la compilación.
cd /usr/local/src/postgresql-8.4.1/src/interfaces
make
make install
Los pasos para la compilación de los módulos específicos son los siguientes:
el módulo nombre_módulo que se desee compilar, para ello se debe utilizar el
comando siguiente:
# cd, cambia el directorio actual a la dirección especificada.
cd /usr/local/src/postgresql-8.4.1/contrib/[nombre_módulo]
Paso 2.- Compilar el módulo seleccionado, para ello se deben emplear los comandos
siguientes:
make
55
Figura 13.- Ejecución del comando make en el módulo fuzzystrmatch
make install
Figura 14.- Ejecución del comando make install en el módulo fuzzystrmatch
Paso 3.- Autenticarse como el usuario postgres para acceder a la plantilla 1

(template1) del gestor, para ello utilice el comando siguiente:
en el terminal. En este caso es utilizado para cambiar para el usuario a postgres.
su - postgres
Paso 4.- Aplicar el módulo al template1 para que todas las bases de datos que se
creen a partir de él hereden sus funcionalidades, para ello escribir el comando
siguiente:
/usr/local/pgsql/bin/psql –f /usr/local/src/postgresql-
8.4.1/contrib/nombre_módulo/nombre_módulo.sql -d template1
56
Figura 15.- Ejecución del comando para aplicarles los cambios a la base de datos template1
5.- Procedimiento para la compilación del módulo PL/R
R es un paquete estadístico de última generación al mismo tiempo que un lenguaje de

programación orientado a objetos de tipo interpretado, lo cual lo hace muy versátil;
ofreciendo gran flexibilidad, gran potencia y en un tiempo de aprendizaje corto.
Paso 1.- Instalar las headers (dependencias) de R para la compilación del lenguaje,
para ello se pueden emplear el comando siguiente:
apt-get install r-base r-base-core r-recommended r-base-dev pkg-config
57
Figura 16.- Ejecución de la instalación de las dependencias
Paso 2.- Definir la variable de entorno R_HOME en el profile del usuario postgres, para
ello se pueden emplear los comandos siguientes:
su - postgres
R_HOME=/usr/lib/R
export R_HOME
Luego como root hacer esto:
R_HOME=/usr/lib/R
export R_HOME
cp -R /usr/share/R/include /usr/lib/R
58
Paso 3.- Instalar plr, para ello se pueden emplear los comandos siguientes:
# cd, cambia el directorio para plr, a quien se le realizará la compilación.
cd /usr/local/src/postgresql-8.4.1/contrib/plr
make
Figura 17.- Ejecución del comando make en el módulo plr
make install
59
Figura 18.- Ejecución del comando make install en el módulo plr
Paso 4.- Reiniciar PostgreSQL, para ello se pueden emplear los comandos siguientes:
/etc/init.d/PostgreSQL restart
Figura 19.- Ejecución del comando para reiniciar PostgreSQL
Paso 5.- Autenticarse como el usuario postgres para acceder a la plantilla 1

(template1) del gestor, para ello utilice el comando siguiente:
su - postgres
Paso 6.- Aplicar el módulo al template1 para que todas las bases de datos que se
creen a partir de él hereden sus funcionalidades, para ello escribir el comando
siguiente:
/usr/local/pgsql/bin/psql –f /usr/local/scr/postgresql-8.4.1/contrib/plr/
plr.sql -d template1
60
Figura 20.- Ejecución del comando para aplicarles los cambios a la base de datos template1
6.- Recomendaciones y buenas prácticas para la personalización de PostgreSQL
Para la personalización y compilación del sistema de gestión de bases de datos

PostgreSQL, es necesario llevar a cabo una serie de recomendaciones y buenas
prácticas para que sea usado satisfactoriamente a la hora de utilizar los módulos del
contrib que forman parte del código fuente del Gestor, lo cual puede servir de gran
ayuda cuando se vayan a asumir dichas tareas.
A continuación se presentarán diferentes aspectos que son de gran importancia para

la configuración de los módulos.
6.1.- Gestión de dependencias
PostgreSQL tiene pocas dependencias al ser un gestor base, al cual se le pueden

agregar módulos nuevos llamados módulos del contrib, por el hecho de que son
contribuciones que se hacen al desarrollo del Gestor para ampliar sus capacidades de
uso para los más diversos proyectos de desarrollo.
Al ser un gestor base, tiene pocas dependencias por esta misma razón, para que
cuando se vaya a usar no dependa de tantas librerías externas y pueda hacerse un
buen uso del mismo, instalando sólo las que hagan falta para ello.
Pero cuando se van a incluir varios módulos del contrib, hay que hacer una buena
gestión de todas las dependencias que se vayan a usar, por el hecho de que muchos
desarrolladores y usuarios instalan las mismas de una forma no muy organizada, por
61
lo que se recomienda conformar una lista completa de todas las dependencias para
así hacer un buen trabajo en este sentido.
Un ejemplo de lo que se ha estado comentando se puede encontrar cuando se quiere

agregar al gestor el lenguaje procedural PL/R, el cual brinda la posibilidad de usar el
lenguaje R, usado como paquete estadístico de última generación y al mismo tiempo
un versátil lenguaje de programación; y sus dependencias son las librerías propias del
mismo: r-base, r-base-core y r-recommended; imprescindibles para usar R29.
Pero antes de que se vaya a incluir algún módulo en el gestor, primero se recomienda
compilar los contenidos de los directorios src/ports y src/interfaces en el árbol de
fuentes del gestor, los cuales proveen de librerías y cabeceras que se usarán en la
compilación de muchos de los módulos que se agregarán luego.
6.2.- Buena organización de los paquetes
Para la organización de los paquetes se recomienda que a la vez que se vayan

agregando nuevos módulos, nuevas aplicaciones, todas se incluyan en el directorio
src/contrib, para que no vayan a interferir con los otros componentes del Gestor,
además de que es el lugar por excelencia de las nuevas inclusiones en el Gestor.
6.3.- Desarrollo de scripts personalizados para la compilación de PostgreSQL
Cuando se están realizando muchas pruebas con el gestor y se necesitan tener varias
versiones del mismo en el servidor en el cual se están realizando dichas pruebas, lo
mejor sería desarrollar scripts personalizados para que el trabajo de compilación,
situado de los archivos, organización y creación del directorio de datos, etc; para que
no sea tan tedioso para los desarrolladores o los probadores. Un ejemplo práctico de
la construcción de un script de este tipo en Linux se muestra a continuación:
29
Las dependencias que se toman de R en este escrito están probadas en el sistema operativo Debian
GNU/Linux 5.0
62
#!/bin/bash
# Default "configure" args. They will be overridden with the contents of a
# CONFIGURE_ARGS file in the source directory.
CONFIGURE_ARGS="--enable-debug --enable-depend --enable-cassert --enable-nls -
-cache-file=/home/alvherre/tmp/pgconfig.@TREE@.cache --enable-thread-safety
--with-python --with-perl --with-tcl --with-openssl --with-libxml"
# The root directory, where everything lies. Defaults to $HOME/CVS/pgsql,
# but can be changed by the PGROOT environment variable.
ROOT=${PGROOT-/pgsql}
# do we have a diff coloring utility?
for prog in cdiff colordiff; do
which $prog >/dev/null 2>/dev/null
if [ $? == 0 ]; then
# COLORDIFF=`which $prog`
break
fi
done
# If the first argument is "_commands", return the list of known commands
if [ ! -z "$1" -a "$1" == '_commands' ]; then
for i in config build install init server client check pcheck tags
changelog rmderived update showdiff touchchanged edit; do
echo $i
done
exit
fi
# If the argument is a file, its contents is the real target. Useful to have
# a "default" build, pointing to whatever is the current development tree.
if [ -f $ROOT/source/$1 ]; then
DIR=`cat $ROOT/source/$1`
else
DIR=$1
fi
SRCDIR=$ROOT/source/$DIR
INSTDIR=$ROOT/install/$DIR
BUILDDIR=$ROOT/build/$DIR
PGDATADIR=$INSTDIR/data
export LD_LIBRARY_PATH=$INSTDIR/lib
63
if [ -z "$DIR" ]; then
LIST=`cd "$SRCDIR" ; find . -maxdepth 1 -mindepth 1 -type d`
echo "I need an argument -- one from:"
for i in $LIST; do
echo -n " "`basename $i`
done | (fmt 2>&1 || true)
echo ""
exit
fi
PGPORT=$((55432+$(echo $BUILDDIR | sed -e 's/^[^0-9]*$[0-9]*$.*$/\1/' -e 's/^0*//' -e
's/^$/0/' )))
# Miscelaneous functions
check_srcdir() {
if [ ! -d $SRCDIR ]; then
echo "The first argument must be a source directory" >&2
ls $ROOT/source >&2
exit
fi
}
check_blddir() {
if [ ! -d $BUILDDIR ]; then
echo "The first argument must be a VPATH build directory" >&2
ls $ROOT/build >&2
exit
fi
}
check_backend() {
backend=$BUILDDIR/src/backend/postgres
if [ ! -f $backend ]; then
echo "The backend must exist at $backend" >&2
exit
fi
}
check_instdir() {
if [ ! -x $INSTDIR/bin/postmaster ]; then
echo "$DIR debe ser un directorio de instalación" >&2
exit
fi
}
64
runpg_config() {
check_srcdir
if [ -d $BUILDDIR ]; then
echo -n "Desea eliminar $BUILDDIR (y/n)? "
unset removed
read answer
if [ ! -z "$answer" ]; then
if [ "$answer" = 's' -o "$answer" = 'y' ]; then
rm -fr $BUILDDIR
removed=t
fi
fi
if [ -z "$removed" ]; then
exit
fi
fi
mkdir $BUILDDIR
if [ -f $SRCDIR/CONFIGURE_ARGS ]; then
CONFIGURE_ARGS=`cat $SRCDIR/CONFIGURE_ARGS`
fi
CONFIGURE_ARGS=${CONFIGURE_ARGS//@TREE@/$DIR}
cd $BUILDDIR
echo $SRCDIR/configure $CONFIGURE_ARGS --prefix=$INSTDIR --with-
pgport=$PGPORT
$SRCDIR/configure $CONFIGURE_ARGS --prefix=$INSTDIR --with-
pgport=$PGPORT
make -C src -s distprep
cd "$OLDPWD"
}
runpg_build() {
check_srcdir
check_blddir
cd $BUILDDIR
LC_ALL=C make -j3 2>&1 >> $BUILDDIR/build.out | tee -a
$BUILDDIR/build.err
LC_ALL=C make -j3 -C contrib 2>&1 >> $BUILDDIR/build.out | tee -a
$BUILDDIR/build.err
cd "$OLDPWD"
}
65
runpg_install() {
check_backend
cd $BUILDDIR
LC_ALL=C make -j3 install 2>&1 >> $BUILDDIR/build.out | tee -a
$BUILDDIR/build.err
LC_ALL=C make -j3 -C contrib install 2>&1 >> $BUILDDIR/build.out | tee
-a $BUILDDIR/build.err
cd "$OLDPWD"
}
# Select the action based on the parameters

case "$2" in
config)
runpg_config
exit $?
;;
build)
runpg_build
exit $?
;;
install)
runpg_install
exit $?
;;
init)
check_instdir
rm -fr $PGDATADIR
$INSTDIR/bin/initdb -D $PGDATADIR
exit $?
;;
server)
check_instdir
if [ ! -z $DISPLAY ]; then
echo -ne "\033]0;$1 server\007"
fi
ulimit -c unlimited
PGDATA=$PGDATADIR exec $INSTDIR/bin/postmaster
exit
;;
66
client)
check_instdir
export PATH=$INSTDIR/bin:$PATH
export PGDATA=$PGDATADIR
if [ ! -f $PGDATA/db_created ]; then
createdb &&
createlang plpgsql &&
createlang plperl &&
createlang pltcl &&
createlang plpythonu &&
touch $PGDATA/db_created
fi
PGCMD=psql
if [ ! -z "$DISPLAY" ]; then
echo -ne "\033]0;$1 client\007"
fi
psql
exit
;;
check)
check_instdir
make -C $BUILDDIR/src/test/regress installcheck
;;
contribcheck)
check_instdir
make -s -C $BUILDDIR/contrib installcheck
;;
pcheck)
check_instdir
cd $BUILDDIR/src/test/regress
make -C $BUILDDIR/src/test/regress installcheck-parallel
;;
tags)
check_srcdir
cd "$SRCDIR"
echo "getting file list for cscope ..."
find $SRCDIR $BUILDDIR $ -name "*.[chly]" -o -iname "*makefile*" -o
-name "*.mk" -o -name "*.in" -o -name "*.sgml" -o -name "*.sh" -o -name
"*.sql" $ -type f > $SRCDIR/cscope.files
echo "building cscope database ..."
67
cscope -b
echo "building tags file ..."
ctags -R
echo "done"
;;
changelog)
check_srcdir
cd "$SRCDIR"
if [ ! -d CVS ]; then
echo "operation is valid only on CVS trees" 1>&2
exit -1
fi
common_args="--revisions --no-indent --no-wrap --separate-header"
branch_arg=""
branch=$(cvs status configure.in | grep 'Sticky Tag' | awk '{print $3}')
if [ $branch != "(none)" ]; then
branch_arg="--follow $branch"
fi
if [ ! -f ChangeLog ]; then
cvs2cl $common_args $branch_arg
else
cvs2cl $common_args $branch_arg --accum
fi
;;
rmderived)
check_srcdir
cd "$SRCDIR"
find . -name .cvsignore | while read line
do
dir=$(dirname $line)
cd $dir
rm -fv `cat .cvsignore`
cd "$OLDPWD"
done
;;
update)
check_srcdir
cd "$SRCDIR"
if [ -d CVS ]; then
;;
68
cvs update -Pd
elif [ -d .svn ]; then
svn update
elif [ -d .git ]; then
echo "not supported for git trees" >&2
exit -1
fi
;;
showdiff)
check_srcdir
cd "$SRCDIR"
if [ ! -z "$COLORDIFF" ]; then
pipe="$COLORDIFF"
else
pipe=cat
fi
if [ -d CVS ]; then
cvs -q diff | $pipe | less -r
svn diff | $pipe | less -r
elif [ -d .git ]; then
git diff
fi
;;
touchchanged)
check_srcdir
cd "$SRCDIR"
if [ -d CVS ]; then
cvs -q diff | grep Îndex | cut -d" " -f2 | xargs touch
svn diff | grep Îndex | cut -d" " -f2 | xargs touch
fi
;;
edit)
check_srcdir
cd "$SRCDIR"
vi -g &
;;
*)
check_instdir
echo "export PATH=$INSTDIR/bin:$PATH"
echo "export MANPATH=$INSTDIR/share/man"
echo "export PGDATA=ècho $PGDATADIR`"
echo "export PGPORT=$PGPORT"
echo "export PGLIBS=$INSTDIR/lib"
echo "export PGINCLUDE=$INSTDIR/include"
;;
esac
69
A continuación se explicarán algunas de las opciones del script:
- config: invoca el comando configure con los parámetros estándares definidos

en el mismo script, o bien que se pueden sobreescribir con un archivo
CONFIGURE_ARGS dentro del árbol del código fuente.
- build: construye todo haciendo un make en el árbol de fuentes.
- install: hace un make install en el árbol de fuentes.
- init: hace un initdb en la ubicación estándar que define el usuario.
- server: inicia el proceso postmaster.
- client: ejecuta la consola de PostgreSQL psql.
- check: ejecuta las pruebas de regresión de tipo serial.
- pcheck: ejecuta las pruebas de regresión en forma paralela.
- tags: actualiza el archivo de ctags y cscope, en caso de que lo estén usando

desarrolladores del gestor.
- changelog: genera el archivo CHANGELOG para la rama que se esté usando

en ese momento usando el comando cvs2cl.
- rmderived: borra los archivos derivados.
- update: hace un cvs update, por el hecho de que los desarrolladores de

PostgreSQL usando CVS como sistema de control de versiones.
- showdiff: hace un cvs diff y lo pasa por un pages. Si se desea guardar en un

parche, se puede redirigir a un fichero en específico.
- touchchanged: hace un touch de todos los archivos modificados. Esto es útil

para forzar a que sean recompilados.
- edit: ejecuta vi -g en el directorio base del código fuente.
- commands: da una lista de órdenes que conoce. Esto es útil para el “bash
completion”.
Notas acerca de la utilización del script: El primer parámetro debe ser el nombre de un
"cvs checkout" de una rama, y el nombre debe empezar con un número, el cual se
suma a 5432 para obtener el nombre de puerto base que se pasa a --with-pgport. El
script creado usa nombres como "84_rel", de manera que cada nombre es fácil de
recordar y quedan en puertos distintos, por lo que se pueden tener los servidores
70
corriendo simultáneamente.
Si uno le da el nombre de la rama pero ninguna otra opción, emite una serie de
definiciones de variables de ambiente. Eso se puede agregar al ambiente existente.
Por ejemplo yo uso `runpg 84_rel` y define PGDATA, PGPORT, y otras cosas útiles.
El código se debe poner en un directorio con esta estructura:
pgsql/
source/
84_rel
83_rel
etc
build/
84_rel
etc
install
Esto se ubica en /pgsql normalmente, pero uno puede definir la variable de ambiente
PGROOT para cambiar esto. Por ejemplo se pudiera tener "export
PGROOT=~/Code/pgsql" o algo por el estilo. Cuando se hace "config" de una rama del
código, se crea el directorio dentro de build y se ejecuta configure; los ficheros .so
quedan en ese otro directorio, lo que se conoce como una construcción VPATH.
7.- Procedimiento para la eliminación de los módulos
Para llevar a cabo la desinstalación de cualquiera de los módulos se debe ejecutar el

fichero unistall_[nombre del módulo].sql generado por la compilación de él mismo
dentro de la base de datos template1.
Los pasos para desinstalar algún módulo desde el código fuente son los siguientes:
Paso 1.- Cambiar el usuario actual al usuario del sistema, para ello puede escribir el
siguiente comando:
su - postgres
Paso 2.- Ejecutar el desinstalador del módulo dentro de la template1, para ello escribir
el comando siguiente:
71
/usr/local/pgsql/bin/psql –f
/usr/local/pgsql/share/contrib/uninstall_[nombre del módulo].sql -d
template1
Figura 21.- Ejecución de la desinstalación del módulo fuzzystrmatch
Paso 3.- Desconectarse como postgres, para ello escribir el comando siguiente:
exit
Paso 4.- Borrar el fichero [nombre del fichero].so que es generado por la compilación,
para ello escribir el comando siguiente:
rm /usr/local/pgsql/lib [nombre del módulo].so
72

Guía para La Personalización de PostgreSQL 8.4

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Guía para La Personalización de PostgreSQL 8.4

Enviado por

Direitos autorais:

Formatos disponíveis

Guía para la personalización de

Personalización con funcionalidades de análisis de datos, monitoreo, administración,

Centro de Tecnologías de Gestión de Datos (DATEC)

Universidad de las Ciencias Informáticas. Ciudad de La Habana, Cuba.

Secciones de la Guía .................................................................................................. 4

Requerimientos para ejecutar la Guía ........................................................................ 4

1.- Descripción del sistema de gestión de bases de datos PostgreSQL ........................ 6

1.1.- Definición de PostgreSQL ................................................................................... 6

1.2.- Funcionalidades de PostgreSQL ........................................................................ 6

1.3.- PostgreSQL 8.4 .................................................................................................. 7

2.- Procedimiento para la instalación y configuración del paquete PostgreSQL 8.4.1

3.- Descripción detallada de los módulos del contrib ................................................... 23

3.1.- Descripción de los módulos de análisis de datos ............................................. 23

3.2.- Descripción de los módulos de monitoreo ........................................................ 27

3.3.- Descripción de los módulos de administración ................................................. 29

3.4.- Descripción de los módulos de desarrollo ........................................................ 37

3.5.- Descripción de los módulos de seguridad ........................................................ 51

5.- Procedimiento para la compilación del módulo PL/R .............................................. 57

6.- Recomendaciones y buenas prácticas para la personalización de PostgreSQL .... 61

6.1.- Gestión de dependencias ................................................................................. 61

6.2.- Buena organización de los paquetes ................................................................ 62

6.3.- Desarrollo de scripts personalizados para la compilación de PostgreSQL ...... 62

7.- Procedimiento para la eliminación de los módulos ................................................. 71

Bienvenido a la Guía para la personalización de PostgreSQL 8.4, la cual está dirigida a

Este prefacio contiene:

- Requerimientos para ejecutar la Guía.

La Guía para la personalización de PostgreSQL 8.4 difunde el conocimiento para la

Esta guía está orientada a:

- Administradores de bases de datos PostgreSQL que deseen adquirir

- Administradores de bases de datos PostgreSQL que necesiten incorporar

Las siguientes convenciones de texto serán usadas en este documento:

Tabla 1.- Convenciones a utilizar durante la Guía

La Guía tiene las siguientes secciones:

- Sistema de gestión de bases de datos PostgreSQL.

- Procedimiento para la instalación y configuración del paquete PostgreSQL

- Descripción detallada de los módulos del contrib.

- Procedimiento para la compilación de los módulos del contrib de PostgreSQL

- Procedimiento para la compilación del módulo PL/R.

- Recomendaciones y buenas prácticas para la personalización de PostgreSQL

- Procedimiento para la eliminación de un módulo.

Requerimientos para ejecutar la Guía

Para ejecutar satisfactoriamente la Guía deben cumplirse los siguientes

- Contar con el código fuente del PostgreSQL 8.4.

- Tener privilegios administrativos en el terminal donde serán ejecutados los

- Estar conectado a los repositorios para la descarga efectiva de los paquetes

- Tener instalados los paquetes:

 GNU make (make): recomendado en su versión 3.76.1 o superior.

 tar, gzip: para descompactar las fuentes.

 Compilador ISO/ANSI C: GCC en este caso, seleccionado como

 zlib: librería de propósito general para la compresión y descompresión

- Tener 65 Mb de espacio en disco para el árbol de código durante la

1.1.- Definición de PostgreSQL

PostgreSQL es un potente sistema de gestión de bases de datos objeto-relacional (O-

1.2.- Funcionalidades de PostgreSQL

Es el gestor de bases de datos de código abierto más avanzado actualmente, ofrece

- Organiza los datos mediante un modelo objeto-relacional.

- Capaz de manejar procedimientos, rutinas complejas y reglas.

- Soporta tablespaces2, transacciones anidadas, copias de seguridad en línea y

- Ofrece transacciones que permiten el paso entre dos estados consistentes

- Es altamente extensible, soporta operadores, funciones, métodos de acceso y

- Soporta integridad referencial, la cual es utilizada para garantizar la validez de

- Las restricciones y disparadores tienen la función de mantener la integridad y

- Usa una arquitectura cliente/servidor basada en un proceso por usuario. Existe