PLR como ejemplo de introducción al uso de lenguajes procedimentales en postgres
Admito que me divierte trastear con bases de datos, una de mis favoritas por su versatilidad y amplio soporte para lenguajes procedimentales es Postgresql. Un lenguaje procedimental no es otra cosa que un medio de insertar código externo en una consulta sql de modo que pueda ser comprendido (y ejecutado) por la base de datos. Postgres incluye soporte maduro para C, Perl, Python, Ruby, PHP, Lua o Scheme entre otros lo que permite ampliar considerablemente las capacidades de SQL y superar muchas de sus limitaciones. Entenderemos mejor lo que puede suponer ésto con un caso práctico: Vamos a ver como crear gráficas desde nuestra base de datos conectándola directamente con un popular programa para análisis estadístico llamado R.
Requisitos mínimos. Necesitaremos una instalación funcional de postgres que tenga disponible la extensión para el lenguaje procedimental correspondiente (la última actualmente en Debian es postgresql-8.4-plr aunque probablemente pronto estará disponible la 9.0). En segundo lugar necesitaremos tener GNU-R instalado. Por si alguien no lo conoce R es un entorno para hacer todo tipo de análisis estadísticos muy completo, muy complejo, a veces peor que un dolor de muelas, pero siempre recomendable. Sin duda alguna una de las joyas de la corona del open-source. Una vez instalado todo cargaremos el lenguaje mediante createlang y comprobamos que todo está en su sitio lanzando un par de comandos de prueba en la consola de postgres.
SELECT r_version();
SELECT * FROM plr_environ();y ya estamos listos para empezar. El paso siguiente es diseñar una nueva función personalizada para envolver nuestro código externo. Como estoy simplemente divirtiéndome y tengo algunas bases de datos taxonómicos disponibles voy a examinar gráficamente el número de especies descritas de algunos invertebrados marinos a lo largo de la historia, concretamente corales, anémonas, medusas y otros colegas. Las tablas sobre la que voy a trabajar (cnidaria y ctenofora) poseen cuatro campos con el nombre científico de las especies que nos ocupan:
gen | sp | autor | año |
-----------+-------------+------------------------------+------+
Malo | maxima | Gershwin |2005 |
Tubularia | chilensis | Hartlaub |1905 |
Tiburonia | granrojo | Matsumoto, Raskoff & Lindsay |2003 |
...De la tabla podemos deducir rápidamente que a los taxónomos también se les va la pinza a la hora de poner nombres; tenemos una gran medusa roja del tamaño de una mesa camilla, una cosita transparente con superpoderes diseñada para el mal y una especie de pelusa pegada a una piedra de vida deplorable. Tres ejemplos de la típica biodiversidad cnidaria.
Vamos al lío, el campo que me interesa de ahí es 'año' y mi nueva función la siguiente:
CREATE OR REPLACE function liberad_a_wili() RETURNS VOID as $$
datos <- pg.spi.exec("select año from cnidaria where año > 1750")
pdf('/tmp/wili.pdf')
layout(matrix(c(1,1,2,1,1,2),3,2))
attach(datos)
hist(año,col='salmon',breaks=52,main='Cnidarios',xlab='',ylab='número de especies descritas')
detach(datos)
datos2 <- pg.spi.exec("select año from ctenofora where año > 1750")
attach(datos2)
hist(año,col='darkblue',breaks=52,main='Ctenóforos',xlab='año',ylab='número de especies descritas')
detach(datos2)
dev.off()
system('chmod a+r /tmp/wili.pdf')
$$ LANGUAGE plr;Los detalles de la función son irrelevantes en este caso aunque cualquier usuario habitual de R podrá entender la mayor parte sin excesivos problemas. Este comando se limita a hacer que la función esté disponible simplemente, tras un rato si todo está bien deberá mostrarnos las palabras CREATE FUNCTION y ahora ya podremos invocarla con un comando muy sencillo:
SELECT liberad_a_wili();Con lo que obtendremos una respuesta algo lacónica:
liberad_a_wili
---------------
(1 fila)
No hay que dejarse engañar, realmente HA sucedido algo; si nos vamos ahora a /tmp encontraremos un nuevo archivo wili.pdf con nuestros resultados.
...y por hoy lo dejaremos aquí.
Gracias por la entrada del blog. Es muy interesante; no sabía que se pudieran conectar PostgreSQL y R. Yo apenas estoy iniciándome en el uso de bases de datos, de momento con OpenOffice Base y HSLQDB, pero me atrae más PostgreSQL, y una información como la que aportas puede serme muy útil en el futuro. También he probado R, aunque no he pasado de instalar y usar una interfaz para KDE, que ya no recuerdo cómo se llama. Seguramente vuelva sobre él más adelante, ya he descargado un manual de PLR. Permíteme unas preguntas: ¿Cómo usas PostgrSQL? ¿Localmente o mediante servidor? ¿Utilizas alguna GUI o empleas sólo SQL?
Gracias de nuevo.
Saludos.
Pues lo uso localmente y sin GUIs. No tengo nada en contra de las GUI pero tras un periodo de aprendizaje me he acostumbrado al terminal psql y ahora me parecen demasiado lentas. Se usarlas y las tengo instaladas pero al final nunca las uso porque no las necesito y además distraen del verdadero trabajo. Me ocurre lo mismo con R, me gusta el terminal desnudo puro y duro que tiene y lo demás son envoltorios que, admito que están bien, pero son innecesarios. Cuando necesito algo más, acudo a programas externos directamente, escribo el código a pelo y lo pego en el terminal. Normalmente Emacs se encarga de esa parte.
Un saludo
Gracias. La interfaz para KDE a la que me refería, por si alguien lee esto y le interesa, es RKWard, pero hay varias más. Saludos.
hombre, acabo de ver que por fín está disponible el paquete para la versión 9.1
postgresql-9.1-plr