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

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.


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)



/var/log/pgsql/logfile.log stop"

;;

restart)



/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)


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.



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.



27

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.

28




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



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.

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.


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,



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.



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

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.



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.

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.



Desarrolladores Peter Mount.





34

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


35




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

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.





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


37




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

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.



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


39



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.

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.



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




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.



42



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



43

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.


44


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.

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.



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.





46

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



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)


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.



48

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



49





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

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.



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.

51



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

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.



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.

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.



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

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.



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.

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.



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.

Paso 2.- Compilar el módulo seleccionado, para ello se deben emplear los comandos

siguientes:


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


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.

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.


Figura 17.- Ejecución del comando make en el módulo plr


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:



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


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

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:



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

Guía para la personalización de PostgreSQL 8.4

Documents

Transcript of Guía para la personalización de PostgreSQL 8.4