Upload
rudolphep
View
1.403
Download
4
Embed Size (px)
Citation preview
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
2
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
3
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.
4
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.
5
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.
6
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.
7
- 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.
8
- 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:
9
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.
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.
apt-get install make tar gzip
10
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.
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.
apt-get install build-essential
11
# 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.
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.
apt-get install libncurses5-dev libreadline5-dev zlib1g-dev
12
# 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.
Paso 6.- Descompactar el paquete PostgreSQL 8.4.1, puede hacerse con el comando
siguiente:
# La opción xvvzf permite extraer archivos .gz compactados.
Paso 7.- Ubicar el directorio desde donde se ejecutarán los comandos del terminal en
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.
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
cd /usr/local/src/PostgreSQL-8.4.1/
tar xvzf PostgreSQL-8.4.1.tar.gz
cd /usr/local/src/
13
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.
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”.
./configure --prefix=/usr/local/pgsql --without-pam --without-ldap --
without-krb5 --enable-thread-safety
14
Figura 5.- Ejecución del comando make
# Instala todos los programas que conforman al PostgreSQL en pgsql (directorio
especificado en ./configure).
make install
make
15
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
16
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
17
usuario ha sido creado sin clave de acceso, por lo que la única forma de convertirse
en él, es siendo root.
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.
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
su - postgres
adduser --system --quiet --home /var/lib/pgsql --shell /bin/bash --group -
-gecos "PostgreSQL administrator" postgres
18
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.
# Crear el directorio donde se almacenarán los logs, mkdir crea un nuevo directorio
en la dirección especificada.
# chown, cambia la propiedad de un usuario y/o grupos de los archivos dados.
Cambia el propietario de pgsql a grupo.usuario postgres.
exit
mkdir /var/log/pgsql/
19
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.
chown postgres.postgres /var/log/pgsql
20
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)
su - postgres -c "/usr/local/pgsql/bin/pg_ctl -
D /var/lib/pgsql/data -l
/var/log/pgsql/logfile.log stop"
;;
restart)
su - postgres -c "/usr/local/pgsql/bin/pg_ctl -
D /var/lib/pgsql/data -l
/var/log/pgsql/logfile.log restart"
;;
*)
echo "Usage: \$0 {start|stop|restart}"
;;
esac
exit 0
_EOF_
21
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.
# 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
chmod 755 /etc/init.d/PostgreSQL
22
Figura 11.- Ejecución del comando para iniciar el sistema
Paso 8.- Iniciar PostgreSQL, para ello se pueden emplear los comandos siguientes:
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.
# 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
nano /etc/profile
/etc/init.d/PostgreSQL start
23
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
24
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
instalación5
Para instalar el módulo desde la distribución de la fuente
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.
25
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)
Elemento Descripción
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
26
cadenas de la serie se considerarán similares si
tienen los mismos códigos.
Fecha de creación 27-02-2006
Lugar de origen Grupo Global de Desarrollo de PostgreSQL
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.
Lenguaje de desarrollo C
Fecha de última versión v 1.32, 02-01-2010
Soporte Grupo Global de Desarrollo de PostgreSQL
Grado de generalización Alto
Tabla 4.- Descripción de PL/R de análisis de datos (bostongis.com, 2010)
Elemento Descripción
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.
Fecha de creación 12-06-2007
Lugar de origen Grupo Global de Desarrollo de PostgreSQL
27
Desarrolladores Joe Conway6.
Lenguaje de desarrollo C
Fecha de última versión v plr-8.3.0.9 ,01-02-2010
Soporte Grupo Global de Desarrollo de PostgreSQL
Grado de generalización Alto
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)
Elemento Descripción
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.
Fecha de creación 12-03-2005
Lugar de origen Grupo Global de Desarrollo de PostgreSQL
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.
Lenguaje de desarrollo C
6 Ver en la Tabla 3 su breve reseña.
28
Fecha de última versión v 1.16, 11-06-2009
Soporte Grupo Global de Desarrollo de PostgreSQL
Grado de generalización Alto
Tabla 6.- Descripción del módulo pg_freespacemap de monitoreo (EnterpriseDB Corporation,
2010), (PostgreSQL CVSweb, 2010), (PostgreSQL Global Development Group, 2010)
Elemento Descripción
Descripción Este módulo proporciona un método para examinar el
mapa de espacio libre.
Fecha de creación 12-02-2006
Lugar de origen Grupo Global de Desarrollo de PostgreSQL
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.
Lenguaje de desarrollo C
Fecha de última versión v1.14, 11-06-2009
Soporte Grupo Global de Desarrollo de PostgreSQL
Grado de generalización Medio
Tabla 7.- Descripción del módulo pg_stat_statements de monitoreo (EnterpriseDB Corporation,
2010), (PostgreSQL CVSweb, 2010), (PostgreSQL Global Development Group, 2010)
Elemento Descripción
7 Ver en la Tabla 5 su breve reseña.
29
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.
Fecha de creación 04-01-2009
Lugar de origen Grupo Global de Desarrollo de PostgreSQL
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.
Lenguaje de desarrollo C
Fecha de última versión v 1.13, 26-02-2010
Soporte Grupo Global de Desarrollo de PostgreSQL
Grado de generalización Alto
3.3.- Descripción de los módulos de administración
Tabla 8.- Descripción del módulo adminpack de administración (EnterpriseDB Corporation,
2010), (PostgreSQL CVSweb, 2010), (PostgreSQL Global Development Group, 2010)
Elemento Descripción
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.
30
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.
Lenguaje de desarrollo C
Fecha de última versión v1.12, 01-01-2009
Soporte Equipo de desarrollo del pgAdmin
Grado de generalización Alto
Tabla 9.- Descripción del módulo oid2name de administración (EnterpriseDB Corporation,
2010), (PostgreSQL CVSweb, 2010), (PostgreSQL Global Development Group, 2010)
Elemento Descripción
31
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.
Fecha de creación 24-01-2001
Lugar de origen Grupo Global de Desarrollo de PostgreSQL
Desarrolladores B. Palmer.
Lenguaje de desarrollo C
Fecha de última versión v 1.37, 26-02-2010
Soporte Grupo Global de Desarrollo de PostgreSQL
Grado de generalización Medio
Tabla 10.- Descripción del módulo pgbench de administración (EnterpriseDB Corporation,
2010), (PostgreSQL CVSweb, 2010), (PostgreSQL Global Development Group, 2010)
Elemento Descripción
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
32
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.
Fecha de creación 15-01-2000
Lugar de origen Grupo Global de Desarrollo de PostgreSQL
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.
Lenguaje de desarrollo C
Fecha de última versión v 1.97, 26-02-2010
Soporte Grupo Global de Desarrollo de PostgreSQL
Grado de generalización Alto
Tabla 11.- Descripción del módulo lo de administración (EnterpriseDB Corporation, 2010),
(PostgreSQL CVSweb, 2010), (PostgreSQL Global Development Group, 2010)
Elemento Descripción
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.
33
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.
Fecha de creación 16-06-1998
Lugar de origen Grupo Global de Desarrollo de PostgreSQL
Desarrolladores Peter Mount.
Lenguaje de desarrollo C
Fecha de última versión v 1.17, 11-07-2006
Soporte Grupo Global de Desarrollo de PostgreSQL
Grado de generalización Medio
34
Tabla 12.- Descripción del módulo pg_standby de administración (EnterpriseDB Corporation,
2010), (PostgreSQL CVSweb, 2010), (PostgreSQL Global Development Group, 2010)
Elemento Descripción
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.
Fecha de creación 08-02-2007
Lugar de origen Grupo Global de Desarrollo de PostgreSQL
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).
Lenguaje de desarrollo C
35
Fecha de última versión v 1.28, 26-02-2010
Soporte Grupo Global de Desarrollo de PostgreSQL
Grado de generalización Alto
Tabla 13.- Descripción del módulo pgrowslocks de administración (EnterpriseDB Corporation,
2010), (PostgreSQL CVSweb, 2010), (PostgreSQL Global Development Group, 2010)
Elemento Descripción
Descripción Proporciona una función de bloqueo de registro para
mostrar información de una tabla especificada.
Fecha de creación 23-04-2006
Lugar de origen Grupo Global de Desarrollo de PostgreSQL
Desarrolladores Tatsuo Ishii.10
Lenguaje de desarrollo C
Fecha de última versión v 1.12, 11-06-2009
Soporte Grupo Global de Desarrollo de PostgreSQL
Grado de generalización Medio
Tabla 14.- Descripción del módulo pgstattuple de administración (EnterpriseDB Corporation,
2010), (PostgreSQL CVSweb, 2010), (PostgreSQL Global Development Group, 2010)
Elemento Descripción
Descripción Proporciona diversas funciones para obtener
estadísticas a nivel de tupla.
Fecha de creación 01-10-2001
Lugar de origen Grupo Global de Desarrollo de PostgreSQL
10
Ver en la Tabla 10 su breve reseña.
36
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.
Lenguaje de desarrollo C
Fecha de última versión v 1.38, 11-06-2009
Soporte Grupo Global de Desarrollo de PostgreSQL
Grado de generalización Alto
Tabla 15.- Descripción del módulo pageinspect de administración (EnterpriseDB Corporation,
2010), (PostgreSQL CVSweb, 2010), (PostgreSQL Global Development Group, 2010)
Elemento Descripción
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.
Fecha de creación 17-05-2007
Lugar de origen Grupo Global de Desarrollo de PostgreSQL
Desarrolladores Heikki Linnakangas.11
Lenguaje de desarrollo C
11
Ver en la Tabla 6 su breve reseña.
37
Fecha de última versión v 1.14, 02-01-2010
Soporte Grupo Global de Desarrollo de PostgreSQL
Grado de generalización Alto
3.4.- Descripción de los módulos de desarrollo
Tabla 16.- Descripción del módulo auto_explain de desarrollo (EnterpriseDB Corporation,
2010), (PostgreSQL CVSweb, 2010), (PostgreSQL Global Development Group, 2010)
Elemento Descripción
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
38
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.
Fecha de creación 19-11-2008
Lugar de origen Grupo Global de Desarrollo de PostgreSQL
Desarrolladores Takahiro Itagaki.12
Lenguaje de desarrollo C
Fecha de última versión v 1.14, 26-02-2010
Soporte Grupo Global de Desarrollo de PostgreSQL
Grado de generalización Alto
Tabla 17.- Descripción del módulo hstore de desarrollo (EnterpriseDB Corporation, 2010),
(PostgreSQL CVSweb, 2010), (PostgreSQL Global Development Group, 2010)
Elemento Descripción
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
Ver en la Tabla 7 su breve reseña.
39
Fecha de creación 05-09-2006
Lugar de origen Grupo Global de Desarrollo de PostgreSQL
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.
Lenguaje de desarrollo C
Fecha de última versión v 1.16 26-02-2010
Soporte Grupo Global de Desarrollo de PostgreSQL
Grado de generalización Alto
Tabla 18.- Descripción del módulo ltree de desarrollo (EnterpriseDB Corporation,
2010), (PostgreSQL CVSweb, 2010), (PostgreSQL Global Development Group, 2010)
Elemento Descripción
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.
40
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.
Fecha de creación 30-07-2002
Lugar de origen Grupo Global de Desarrollo de PostgreSQL
Desarrolladores Teodor Sigaev.13
Oleg Bartunov.14
Lenguaje de desarrollo C
Fecha de última versión v 1.27, 24-02-2010
Soporte Grupo Global de Desarrollo de PostgreSQL
Grado de generalización Alto
Tabla 19.- Descripción del módulo pg_trgm de desarrollo (EnterpriseDB Corporation, 2010),
(PostgreSQL CVSweb, 2010), (PostgreSQL Global Development Group, 2010)
Elemento Descripción
13
Ver en la Tabla 17 para su breve reseña.
14 Ver en la Tabla 17 para su breve reseña.
41
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.
Fecha de creación 03-05-2004
Lugar de origen Grupo Global de Desarrollo de PostgreSQL
Desarrolladores Teodor Sigaev.15
Oleg Bartunov.16
Lenguaje de desarrollo C
Fecha de última versión v 1.16, 11-06-2009
Soporte Grupo Global de Desarrollo de PostgreSQL
Grado de generalización Medio
Tabla 20.- Descripción del módulo seg de desarrollo (EnterpriseDB Corporation, 2010),
(PostgreSQL CVSweb, 2010), (PostgreSQL Global Development Group, 2010)
Elemento Descripción
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 Ver en la Tabla 17 para su breve reseña.
16 Ver en la Tabla 17 para su breve reseña.
42
Fecha de creación 11-12-2000
Lugar de origen Grupo Global de Desarrollo de PostgreSQL
Desarrolladores Gene Selkov.17
Lenguaje de desarrollo C
Fecha de última versión v 1.25, 11-06-2009
Soporte Grupo Global de Desarrollo de PostgreSQL
Grado de generalización Medio
Tabla 21.- Descripción del módulo tablefunc de desarrollo (EnterpriseDB Corporation, 2010),
(PostgreSQL CVSweb, 2010), (PostgreSQL Global Development Group, 2010)
Elemento Descripción
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.
Fecha de creación 30-07-2002
Lugar de origen Grupo Global de Desarrollo de PostgreSQL
Desarrolladores Joe Conway.18
Lenguaje de desarrollo C
Fecha de última versión v 1.62, 02-01-2010
Soporte Grupo Global de Desarrollo de PostgreSQL
Grado de generalización Alto
17
Ver en la Tabla 2 para su breve reseña.
18 Ver en la Tabla 3 para su breve reseña.
43
Tabla 22.- Descripción del módulo uuid-ossp de desarrollo (EnterpriseDB Corporation, 2010),
(PostgreSQL CVSweb, 2010), (PostgreSQL Global Development Group, 2010)
Elemento Descripción
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.
Fecha de creación 21-04-2007
Lugar de origen Grupo Global de Desarrollo de PostgreSQL
Desarrolladores Peter Eisentraut.
Lenguaje de desarrollo C
Fecha de última versión v 1.12, 02-01-2010
Soporte Grupo Global de Desarrollo de PostgreSQL
Grado de generalización Alto
Tabla 23.- Descripción del módulo citext de desarrollo (EnterpriseDB Corporation, 2010),
(PostgreSQL CVSweb, 2010), (PostgreSQL Global Development Group, 2010)
Elemento Descripción
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.
Fecha de creación 29-07-2008
44
Lugar de origen Grupo Global de Desarrollo de PostgreSQL
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.
Lenguaje de desarrollo C
Fecha de última versión v 1.3, 05-09-2008
Soporte Grupo Global de Desarrollo de PostgreSQL
Grado de generalización Alto
Tabla 24.- Descripción del módulo dict_xsyn de desarrollo (EnterpriseDB Corporation, 2010),
(PostgreSQL CVSweb, 2010), (PostgreSQL Global Development Group, 2010)
Elemento Descripción
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.
45
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.
Fecha de creación 15-10-2007
Lugar de origen Grupo Global de Desarrollo de PostgreSQL
Desarrolladores Sergey Karpov.
Lenguaje de desarrollo C
Fecha de última versión v 1.9, 26-02-2010
Soporte Grupo Global de Desarrollo de PostgreSQL
Grado de generalización Medio
Tabla 25.- Descripción del módulo spi de desarrollo (EnterpriseDB Corporation, 2010),
(PostgreSQL CVSweb, 2010), (PostgreSQL Global Development Group, 2010)
Elemento Descripción
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.
Fecha de creación 11-09-1997
Lugar de origen Grupo Global de Desarrollo de PostgreSQL
Desarrolladores Teodor Sigaev.20
20 Ver en la Tabla 17 para su breve reseña.
46
Oleg Bartunov.21
Lenguaje de desarrollo C
Fecha de última versión v 1.35, 11-06-2009
Soporte Grupo Global de Desarrollo de PostgreSQL
Grado de generalización Medio
Tabla 26.- Descripción del módulo test_parser de desarrollo (EnterpriseDB Corporation, 2010),
(PostgreSQL CVSweb, 2010), (PostgreSQL Global Development Group, 2010)
Elemento Descripción
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.
Fecha de creación 15-10-2007
Lugar de origen Grupo Global de Desarrollo de PostgreSQL
Desarrolladores Sergey Karpov.22
Lenguaje de desarrollo C
Fecha de última versión v 1.7, 02-01-2010
Soporte Grupo Global de Desarrollo de PostgreSQL
Grado de generalización Medio
Tabla 27.- Descripción del módulo btree_gin de desarrollo (EnterpriseDB Corporation, 2010),
(PostgreSQL CVSweb, 2010), (PostgreSQL Global Development Group, 2010)
Elemento Descripción
21
Ver en la Tabla 17 para su breve reseña.
22 Ver en la Tabla 24 para su breve reseña.
47
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)
Fecha de creación 25-03-2009
Lugar de origen Grupo de Desarrollo Global de PostgreSQL
Desarrolladores Teodor Sigaev.24
Oleg Bartunov.25
Lenguaje de desarrollo C
Fecha de última versión v 1.4, 07-01-2010
23
Estructuras de árbol que se encuentran comúnmente en las implementaciones de bases de datos y
sistemas de archivos.
24 Ver en la Tabla 17 para su breve reseña.
25 Ver en la Tabla 17 para su breve reseña.
48
Soporte Grupo de Desarrollo Global de PostgreSQL
Grado de generalización Medio
Tabla 28.- Descripción del módulo btree_gist de desarrollo (EnterpriseDB Corporation, 2010),
(PostgreSQL CVSweb, 2010), (PostgreSQL Global Development Group, 2010)
Elemento Descripción
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.
Fecha de creación 28-05-2004
Lugar de origen Universidad de California en Berkeley GiST
Desarrolladores Teodor Sigaev.26
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
Ver en la Tabla 17 para su breve reseña.
27 Ver en la Tabla 17 para su breve reseña.
49
Lenguaje de desarrollo C
Fecha de última versión v 1.23, 26-02-2010
Soporte Grupo Global de Desarrollo de PostgreSQL
Grado de generalización Alto
Tabla 29.- Descripción del módulo earthdistance de desarrollo (EnterpriseDB Corporation,
2010), (PostgreSQL CVSweb, 2010), (PostgreSQL Global Development Group, 2010)
Elemento Descripción
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
50
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.
Fecha de creación 16-06-1998
Lugar de origen Grupo Global de Desarrollo de PostgreSQL
Desarrolladores Bruno Wolff III.
Hal Snyder.
Lenguaje de desarrollo C
Fecha de última versión v 1.19, 10-11-2007
Soporte Grupo Global de Desarrollo de PostgreSQL
Grado de generalización Medio
Ubicación Directorio contrib del paquete de instalación de
PostgreSQL 8.4.1.
Tabla 30.- Descripción del módulo isn de desarrollo (EnterpriseDB Corporation, 2010),
(PostgreSQL CVSweb, 2010), (PostgreSQL Global Development Group, 2010)
Elemento Descripción
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.
51
Fecha de creación 09-09-2006
Lugar de origen Grupo Global de Desarrollo de PostgreSQL
Desarrolladores Germán Méndez Bravo.
Lenguaje de desarrollo C
Fecha de última versión v 1.14, 26-02-2010
Soporte Grupo Global de Desarrollo de PostgreSQL
Grado de generalización Medio
Ubicación Directorio contrib del paquete de instalación de
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),
(PostgreSQL CVSweb, 2010), (PostgreSQL Global Development Group, 2010)
Elemento Descripción
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
52
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.
Fecha de creación 03-05-2001
Lugar de origen Grupo Global de Desarrollo de 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.
Lenguaje de desarrollo C
Fecha de última versión v 1.21, 11-06-2009
Soporte Grupo Global de Desarrollo de PostgreSQL
Grado de generalización Alto
Tabla 32.- Descripción del módulo pgcrypto de seguridad (EnterpriseDB Corporation, 2010),
(PostgreSQL CVSweb, 2010), (PostgreSQL Global Development Group, 2010)
Elemento Descripción
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.
53
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.
Fecha de creación 31-10-2000
Lugar de origen Grupo Global de Desarrollo de PostgreSQL
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.
Lenguaje de desarrollo C
Fecha de última versión v 1.33, 11-06-2009
Soporte Grupo Global de Desarrollo de PostgreSQL
Grado de generalización Alto
Tabla 33.- Descripción del módulo veil de seguridad (doxygen, 2010), (pgfoundry.org, 2010)
Elemento Descripción
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
54
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.
Fecha de creación 04-10-2005
Lugar de origen Grupo Global de Desarrollo de PostgreSQL
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
Soporte Grupo Global de Desarrollo de PostgreSQL
Grado de generalización Alto
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.
55
# Primer paso del proceso de compilación.
# Segundo paso del proceso de compilación.
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.
# Primer paso del proceso de compilación.
# Segundo paso del proceso de compilación.
Los pasos para la compilación de los módulos específicos son los siguientes:
Paso 1.- Ubicar el directorio desde donde se ejecutarán los comandos del terminal en
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.
Paso 2.- Compilar el módulo seleccionado, para ello se deben emplear los comandos
siguientes:
# Primer paso del proceso de compilación.
make
cd /usr/local/src/postgresql-8.4.1/contrib/[nombre_módulo]
make install
make
cd /usr/local/src/postgresql-8.4.1/src/interfaces
make install
make
cd /usr/local/src/postgresql-8.4.1/src/port
56
Figura 13.- Ejecución del comando make en el módulo fuzzystrmatch
# Segundo paso del proceso de compilación.
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:
# su, comando usado para convertirse en otro usuario durante una sesión registrada
en el terminal. En este caso es utilizado para cambiar para el usuario a 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:
su - postgres
make install
/usr/local/pgsql/bin/psql –f /usr/local/src/postgresql-
8.4.1/contrib/nombre_módulo/nombre_módulo.sql -d template1
57
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
58
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:
Luego como root hacer esto:
R_HOME=/usr/lib/R
export R_HOME
cp -R /usr/share/R/include /usr/lib/R
su - postgres
R_HOME=/usr/lib/R
export R_HOME
59
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.
# Primer paso del proceso de compilación.
Figura 17.- Ejecución del comando make en el módulo plr
# Segundo paso del proceso de compilación.
make install
make
cd /usr/local/src/postgresql-8.4.1/contrib/plr
60
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:
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, comando usado para convertirse en otro usuario durante una sesión registrada
en el terminal. En este caso es utilizado para cambiar para el usuario a 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:
su - postgres
/etc/init.d/PostgreSQL restart
/usr/local/pgsql/bin/psql –f /usr/local/scr/postgresql-8.4.1/contrib/plr/
plr.sql -d template1
61
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
62
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
63
#!/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.@[email protected] --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
64
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
}
65
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"
}
66
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
;;
67
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 ..."
68
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
;;
69
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
elif [ -d .svn ]; then
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 ^Index | cut -d" " -f2 | xargs touch
elif [ -d .svn ]; then
svn diff | grep ^Index | 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=`echo $PGDATADIR`"
echo "export PGPORT=$PGPORT"
echo "export PGLIBS=$INSTDIR/lib"
echo "export PGINCLUDE=$INSTDIR/include"
;;
esac
70
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
71
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:
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, comando usado para convertirse en otro usuario durante una sesión registrada
en el terminal. En este caso es utilizado para cambiar para el usuario a postgres.
Paso 2.- Ejecutar el desinstalador del módulo dentro de la template1, para ello escribir
el comando siguiente:
su - postgres
pgsql/
source/
84_rel
83_rel
etc
build/
84_rel
etc
install
72
Figura 21.- Ejecución de la desinstalación del módulo fuzzystrmatch
Paso 3.- Desconectarse como postgres, para ello escribir el comando siguiente:
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
exit
/usr/local/pgsql/bin/psql –f
/usr/local/pgsql/share/contrib/uninstall_[nombre del módulo].sql -d
template1