PRIMER AVANCE DEL PROYECTO FINAL

POSTGRESQL
1. DESCRIPCIN GENERAL DE POSTGRESQL
PostgreSQL es un sistema de gestin de base de datos de software libre y de tipo objeto-relacional fue
desarrollado en el Departamento de nformtica de la Universidad de California (Berkeley)
El lder del proyecto, Michael Stonebraker abandon Berkeley para comercializar ngres en 1982, pero
regres a la academia. Tras su retorno a Berkeley en 1985, Stonebraker comenz un proyecto post-ngres
para resolver los problemas con el modelo de base de datos relacional que haban sido aclarados a
comienzos de los aos 1980. El principal de estos problemas era la incapacidad del modelo relacional de
comprender "tipos", es decir, combinaciones de datos simples que conforman una nica unidad.
Actualmente estos son llamados objetos.
El proyecto resultante, llamado PostgreSQL, era orientado a introducir la menor cantidad posible de
funcionalidades para completar el soporte de tipos. Estas funcionalidades incluan la habilidad de definir
tipos, pero tambin la habilidad de describir relaciones - las cuales hasta ese momento eran ampliamente
utilizadas pero mantenidas completamente por el usuario. En PostgreSQL la base de datos "comprenda"
las relaciones y poda obtener informacin de tablas relacionadas utilizando reglas.
Comenzando en 1986, el equipo liber una serie de documentos describiendo la base del sistema y en 1988
posean un prototipo funcional. La versin 1 fue liberada a un pequeo grupo de usuarios en junio de 1989,
seguido por la versin 2 con un sistema de reglas reescrito en junio de 1990. Para la versin 3, liberada en
1991, el sistema de reglas fue reescrito nuevamente, pero tambin agreg soporte para mltiples
administradores de almacenamiento y un sistema de consultas mejorado. Hacia 1993, PostgreSQL haba
crecido inmensamente en popularidad y posea una demanda asfixiante de nuevas funcionalidades. Tras
liberar la versin 4, la cual era una simple versin de limpieza, el proyecto fue abandonado.
A pesar de que el proyecto PostgreSQL hubiese finalizado oficialmente, la licencia BSD bajo la cual
PostgreSQL haba sido liberado permiti a desarrolladores de cdigo abierto el obtener una copia del cdigo
para continuar su desarrollo.
Ahora PostgreSQL es una alternativa a otros sistemas de bases de datos de cdigo abierto e incluso de
sistemas propietarios. Posee las ventajas del Software Libre, es una plataforma estable y es una buen a
opcin para aquellas organizaciones que no cuentan con la economa suficiente para obtener un manejador
comercial.
Los sistemas de mantenimiento de Bases de Datos relacionales tradicionales (DBMS,s) soportan un modelo
de datos que consisten en una coleccin de relaciones con nombre, que contienen atributos de un tipo
especfico. En los sistemas comerciales actuales, los tipos posibles incluyen numricos de punto flotante,
enteros, cadenas de caracteres, cantidades monetarias y fechas. Est generalmente reconocido que este
modelo ser inadecuado para las aplicaciones futuras de procesado de datos. El modelo relacional sustituy
modelos previos en parte por su "simplicidad espartana". Sin embargo, como se ha mencionado, esta
simplicidad tambin hace muy difcil la implementacin de ciertas aplicaciones.
PostgreSQL ofrece una potencia adicional sustancial al incorporar los siguientes cuatro conceptos
adicionales bsicos en una va en la que los usuarios pueden extender fcilmente el sistema:
- Clases
- Herencia
- Tipos
Otras caractersticas son:
- Restricciones (Constrainsts) - Reglas
- Disparadores (Ttriggers) - ntegridad Transaccional
Estas caractersticas colocan a PostgreSQL en la categora de las Bases de Datos identificadas como
objeto-relacionales. PostgreSQL tiene algunas caractersticas que son propias del mundo de las bases de
datos orientadas a objetos. De hecho, algunas Bases de Datos comerciales han incorporado recientemente
caractersticas en las que PostgreSQL fue pionera. .
2. REQUERIMIENTOS PARA SU INSTALACIN Y PLATAFORMAS EN LAS QUE
SE PUEDE INSTALAR.
2.1. Requerimien!" #e In"$%$&i'n
La cantidad mnima de memoria que se requiere para ejecutar PostgreSQLQL es de slo 8 MB. Sin
embargo, se verifica una notable mejora en la velocidad cuando sta se expande a 128 MB o ms de
acuerdo a las necesidades de informacin a manejar.
Se recomienda tener el suficiente espacio en disco duro para el almacenaje de informacin. De antemano
se necesitar como mnimo 30 MB para los archivos con el cdigo fuente durante la compilacin
(instalacin), y unos 15 MB para el directorio de instalacin. Una base de datos vaca ocupa
aproximadamente 1 MB, de no estar vaca, la base ocupar unas cinco veces el espacio que ocupara un
archivo de texto que contuviera los mismos datos, de tal manera que si ejecuta las pruebas de consultas de
datos, necesitar alrededor de 50 MB extra como espacio temporal.
NOTA: Esto es como requerimiento mnimos, para una adecuada instalacin se requiere hacer un estudio
de la informacin a manejar as como los accesos concurrentes que pueden existir a la base de datos,
velocidad deseada en la respuesta en registros de transacciones, tiempos de respuesta en peticiones
internas, etc.
Con respecto a las caractersticas del procesador se mencionarn en el punto 2.2 las plataformas
soportadas al igual que el sistema operativo.
Es recomendable adicionalmente contar con un sistema de respaldos y de arreglos RAD tipo "X segn el
desempeo deseado para la base de datos.
2.2. P%$$(!rm$" en %$" que "e )ue#e in"$%$r
De principio podemos comentar que en general, en cualquier plataforma compatible con UNX es posible
instalar PostgreSQLQL. A continuacin mencionaremos las plataformas actualmente probadas y en las
cuales se garantiza su correcto funcionamiento:
OS Procesador Versin
AX RS6000 7.3
BeOS X86 7.2
BSD/OS X86 7.3
DG/UX 5.4R4.11 M88k 6.3
FreeBSD Alpha 7.3
FreeBSD X86 7.3
HP-UX PA-RSC 7.3
RX MPS 7.3
Linux Alpha 7.3
OS Procesador Versin
Linux armv4l 7.2
Linux MPS 7.2
Linux PlayStation 2 7.3
Linux PPC74xx 7.3
Linux S/390 7.3
Linux Sparc 7.3
Linux X86 7.3
MacOS X PPC 7.3
MkLinux DR1 PPC750 7.0
NetBSD Alpha 7.2
OS Procesador Versin
NetBSD arm32 7.3
NetBSD M68k 7.0
NetBSD MPS 7.2.1
NetBSD X86 7.3
OpenBSD Sparc 7.3
NetBSD PPC 7.2
NetBSD Sparc 7.2
NetBSD VAX 7.1
NeXTSTEP X86 6.x
OpenBSD X86 7.3
QNX 4 RTOS X86 7.2
QNX RTOS v6 X86 7.2
SCO OpenServer
5
X86 7.3.1
Solaris Sparc 7.3
Solaris x86 7.3
SunOS 4 Sparc 7.2
System V R4 m88k 6.2.1
System V R4 MPS 6.4
Tru64 UNX Alpha 7.3
Ultrix MPS 7.1
Ultrix VAX 6.x
UnixWare x86 7.3
Windows x86 7.3 x86 7.3
Windows x86 7.3 x86 7.3
En los sistemas como Windows NT y 2000 pueden correr de igual manera PostgreSQLQL usando los
paquetes auxiliares Cygwin y Cygipc.
*. ESTRUCTURA DE LA +ASE DE DATOS.
La distribucin de los archivos de Postgres muestra cmo se ordena Postgres en el disco cuando es
instalada de la forma usual. Para simplificar, se asume que Postgres se ha instalado en el
directorio /usr/local/pgsql.
Todas los rdenes de Post gres se instalan en el directorio /usr/local/pgsql/bin. Por consiguiente,
debera incluir este directorio en la variable de entorno de path. Si se utiliza un intrprete de rdenes
derivado del !er"ele# e, como csh o tcsh, se inclu#e la lnea
set path $ % /usr/local/pgsql/bin path &
en el archivo .login de su directprio particular %home&. Si, en cambio, se utiliza un intrprete de
rdenes derivado del !ourne, como 'sh, "sh o bash, se deber( agregar las lneas)
P * T+$/usr/local/pgsql/bin),P * T+ e-port P * T+
al archivo .profile ubicado en su directorio de inicio.
Si el servidor de base de datos est( ubicado en una m(quina remota, se necesitar( colocar el nombre
del servidor en la variable de entorno P.+/ST.
*.1. E"ru&ur$ #e &!ne,i'n-
0(-imo tama1o de una base de datos 2limitado %e-isten bases de 34.!&
0(-imo tama1o de una tabla %35 T! en todos los sistemas operativo s &
0(-imo tama1o de un rengln 2limitado de la versin 6.7 en adelante
0(-imo tama1o de un campo 7 .! de la versin 6.7 en adelante
0(-imo n8mero de renglones en una tabla 2limitado
0(-imo n8mero de columnas en una tabla) 7344
0(-imo n8mero de ndices en una tabla ilimitado
*.2. Arquie&ur$ E,ern$-
9na base de datos Postgrsql puede necesitar alrededor de : veces el espacio que ocupara un
archivo de te-to.
;omo e<emplo, podemos considerar un archivo de 744,44 lneas con enteros # te-to como
descripcin en cada lnea. Supongamos que la cadena de te-to tiene una longitud de =4 b#te s como
promedio. >l archivo plano debera ser de =.? 0!. >l tama1o del archivo en la base de datos que
contendr( estos datos se puede estimar en 3.5 0!)
@3 b#tes) por cada cabecera de rengln %apro-imadamente&
=5 b#tes) uno en el campo entero # uno en el campo de te-to
A 5 b#tes) puntero en la p(gina
35 b#te s por rengln
>l tama1o de la p(gina de datos en PostgreSBL es ?7C= b#te s %? D!&, as que tenemos)
?7C= b#tes por p(gina
EEEEEEEEEEEEEEEEEEEE$ 7=? columnas por p(gina en la base de datos %redondeado&
35 b#tes por rengln
744444 renglones de datos
EEEEEEEEEEEEEEEEEEEE$ 6?= p(ginas en la base de datos %redondeado&
7=? renglones por p(gina
6?= p(ginas en la base de datos F ?7C= b#te s por p(gina $ 3,543,755 b#tes %3.5 0!&
Los ndices no fueron requeridos en los c(lculos, de hacerla el tama1o podra ser mas largo.
;lient +ost
Server +ost
Post0aster
9suario de
*plicacion
LibPg
;lient +ost
Server +ost
Post0aster
9suario de
*plicacion
LibPg
Server
*.*. Arquie&ur$ inern$-
3.3.1 Estructura de la pgina.
>sta es una visin general del formato de p(gina utilizado por las clases de Postgres. Los
mtodos de acceso definidos por el usuario no necesitan utilizar este fonnato de p(gina.
Se asume que un byte contiene ? bits. *dem(s, el tnnino campo se refiere a los datos almacenados
en una clase de Postgres.
La siguiente tabla muestra como est(n estructuradas las p(ginas tanto en las clases nonnales de
Postgres como en las clases de ndices de Postgres %es decir, un ndice !Etree&. '
Los primeros ? b#tes de cada p(gina consisten en la cabecera de la p(gina %Ppage+eaderGata&.
Gentro de la cabecera, los primeros tres campos enteros de = b#tes (menor, mayor # especiaT)
representan b#tes que refle<an el principio del espacio desocupado, el final del espacio desocupado,
# el principio del espacio especial. >l espacio especial es una regin al final de la p(gina que se
ocupa en la inicializacin de la p(gina # que contiene infonnacin especfica sobre un mtodo de
acceso. Los dos 8ltimos = b#te s de la cabecera de p(gina, opaco, codifica el tama1o de la p(gina e
informacin sobre la fragmentacin interna de la misma. >l tama1o de la p(gina se almacena en
cada una de ellas, porque las estructuras del pool de buffers pueden estar subdivididas en una fonna
estructura por estructm)a dentro de una clase. La infonnacin sobre la fragmentacin interna se
utiliza para a#udar a detenninar cuando debera realizarse la reorganizacin de la p(gina.
Siguiendo a la cabecera de la p(gina est(n los identificadores de campo (ItemIdData). Se sit8an
nuevos identificadores de campo a partir de los primeros cuatro b#tes de espacio libre. Gebido a que
un identificador de campo nunca se mueve hasta que se elimina, este ndice se puede utilizar para
indicar la situacin de un campo en la p(gina. Ge hecho, cada puntero a un campo (ItemPointer)
creado por Postgres consiste en un n8mero de estructura # un ndice de un identificador de campo.
9n identificador de campo contiene un b#te de referencia al principio de un campo, su longitud en
b#tes, # un con<unto de bits de atributos que pueden afectar a su interpretacin.
Los campos mismos est(n almacenados en un espacio situado m(s all( del final del espacio libre.
+abitualmente, los campos no son interpretados. Sin embargo, cuando el campo es demasiado largo
para ser situado en una 8nica p(gina o cuando se desea la fragmentacin del campo, ste mismo se
divide # cada parte se manipula como campos distintos de la siguiente manera. ;ada una de las
partes en que se descompone se sit8a en una estructura de continuacin de campo
;lient +ost
Server +ost
Post0aster
9suario de
*plicacion
LibPg
Server
(ItemContinuationData). >sta estructura contiene un puntero %2temPointerGata& hacia la siguiente
parte. La 8ltima de estas partes se manipula normalmente.
*... E"ru&ur$ #e #ire&!ri!"-
/var/lib/pgsql/data
Ar&/i0!"-
Bajo el directorio $PGDATA (por defecto RH /var/lib/pgsql/data)
Definen el comportamiento del motor de Base de Datos
Principales archivos:
E pg_hba.conf
Server Process

Traffic;op ;ommands
Parser HeIriter /ptimizer/
Planner
><ecutor
;luster Girector#
!ase pgJclog .lobal pgJ-log
73:5
%Sample G!&
7
%Template 4&
7=56
%pgJt#pe&
7=5C
%pgJattribute&
7=::
%pgJclass&
73C6
%;ustomer&
73CC
%department&
7764
%staff&
7=34
%pgJshadoI&
7=37
%pggroup&
735@4
%inde-&
E pg_indent.conf
E posgresql.conf
3.4 Estructura interna del motor de Postgresql
3.4.1 El camino de una consulta
>sta es una corta revisin a los pasos que debe seguir una consulta hasta ohtener un
resultado.
7. Se ha establecido una cone-in desde un programa de aplicacin al servidor Postgres. >l
programa de aplicacin transmite una consulta # recibe el resultado enviado por el servidor.
=. La etapa del parser (traductor) chequea la consulta transmitida por el programa de aplicacin
%cliente& para comprobar que la sinta-is es correcta # crear un rbol de la consulta.
@. >l sistema de re escritura toma el (rbol de la consulta creado en el paso del traductor # busca
reglas %almacenadas en los catlogos del sistema) que pueda aplicarle al rbol de la consulta #
realiza las transformaciones que se dan en el/los cuerpo/s de la/s regla/s. >ncontramos una
aplicacin del sistema de reescritura en la realizacin de las vistas.
Siempre que se realiza una consulta contra una vista %es decir, una tabla virtual), el sistema de
reescritura reescribe la consulta del usuario en una consulta que accede a las tablas base dadas
en la definicin de la vista inicial.
5. >l planeador/optimi!ador toma el (rbol de la consulta %reescrita& # crea un plan de
la consulta que ser( el input para el e"ecutor.
+ace esto creandp previamente todas las posibles rutas que le conducen a un mismo resultado.
Por e<emplo, si ha# un ndice en una relacin que debe ser comprobada, ha# dos rutas para
comprobada. 9na posibilidad es un simple barrido secuencial # la otra posibilidad es utilizar el
ndice. Luego se estima el coste de e<ecucin de cada plan, # se elige # e<ecuta el plan m(s
r(pido.
:. >l e<ecutor realiza de modo re cursivo el rbol del plan # recupera tuplas en la forma
representada en el plan. >l e<ecutor hace uso del sistema de almacenamiento mientras est(
revisando las relaciones, realiza ordenaciones (sorts) # "oins, eval8a cualificaciones # finalmente
devuelve las tuplas derivadas.
3.4.2 Cmo se establecen las conexiones
Postgres est( implementado como un simple modelo cliente / servidor a Kproceso por usuarioK. >n
este modelo ha# un proceso cliente conectado a e-actamente un proceso servidor. ;omo nosotros
no conocemos perse cuantas cone-iones se har(n, se utiliza un
proceso master que lanza un nuevo proceso servidor para cada cone-in que se solicita. >ste
proceso master se llama postmaster # escucha en un puerto T;P/2P especfico a las cone-iones
entrantes. ;ada vez que se detecta un requerimiento de cone-in, el proceso postmaster lanza un
nuevo proceso servidor llamado Postgres. Las tareas de servidor %los procesos postgres) se
comunican unos con otros utilizando semforos # memoria compartida %shared memor#& para
asegurar la integridad de los datos a travs de los accesos concurrentes a los datos.
>l proceso cliente puede ser la interface de usuario %frontend& psql %para realizar consultas SBL
interactivas& o cualquier aplicacin de usuario implementada utilizando la biblioteca libpg.
Ltese que las aplicaciones implementadas utilizando ecpg %el preprocesador de SBL
embebido de Postgres para ;& tambin utiliza esta biblioteca.
9na vez que se ha establecido una cone-in, el proceso cliente puede enviar una consulta al
servidor (bac#end). >sta consulta se transmite utilizando un te-to plano, es decir, no se ha hecho
una traduccin en el cliente (frontend). >l servidor traduce la consulta, crea un plan de e"ecucin,
e<ecuta el plan # remite las tuplas recuperadas al cliente a travs de la cone-in establecida.
3.4.3 La etapa de traduccin
Traductor
>l traductor debe comprobar la cadena de caracteres de la consulta %que le llega como te-to *S;22
plano& para comprobar la validez de la sinta-is. Si la sinta-is es correcta, se constru#e un rbol de
traduccin # se devuelve un mensa<e de error en otro caso. Para la implementacin se han utilizado
las bien conocidas herramientas de 9ni- le- # #acc.
>l lector %le-er& se define en el fichero sean.7 # es el responsable de reconocer los
identificadores, las palabras clave de $%&, etc. Para cada palabra clave o identificador que
encuentra, se genera # traslada al traductor traductor una se'al.
>l traductor est( definido en el fichero gramo # # consiste en un con<unto de reglas de gramtica #
acciones que ser(n e<ecutadas cada vez que se dispara una regla. >l cdigo de las acciones %que
actualmente es cdigo ;& se utiliza para construir el (rbol de traduccin.
>l fichero sean.1 se transforma en el fichero fuente ; sean. e utilizando el programa le- u gram. # se
transforma en gram. e utilizando #acc. 9na vez se han realizado estas transformaciones, cualquier
compilador ; puede utilizarse para crear el traductor. Lo se deben nunca realizar cambio en los ficheros
e generados, pues ser(n sobrescritos la pr-ima vez que sean llamados le- o #acc.
Proceso de transformacin
>l proceso de transformacin toma el (rbol producido por el traductor como entrada # procede
recursivamente a travs su#o. Si se encuentra un nodo SelectStmt, se transforma en un
nodo Query que ser( el nodo superior de la nueva estructura de datos.
*hora se realiza una comprobacin sobre si los nombres de relaciones de la clusula ()*+ son
conocidas por el sistema. Para cada nombre de relacin que est( presente en los catlogos del
sistema, se crea un nodo HT> que contiene el nombre de la relacin, el nombre del alias # el
identificador (id) de la relacin. * partir de ahora, se utilizan los identificadores de relacin para
referirse a las relaciones dadas en la consulta. Todos los nodos HT> son recogidos en la lista de
entradas de la tabla de rango que est( conectada al campo rtable del nodo Buer#. Si se detecta
en la consulta un nombre de relacin desconocido para el sistema, se devuelve un error # se
aborta el procesado de la consulta.
>l siguiente paso es comprobar si los nombres de atributos utilizados est(n contenidos en las
relaciones dadas en la consulta. Para cada atributo que se encuentra se crea un nodo TL> que
contiene un puntero a un nodo Resdom %que contiene el nombre de la columna& #
un puntero a un nodo M*H. +a# dos n8meros importantes en el nodo M*H. >l campo varno
da la posicin de la relacin quNcontiene el atributo actual en la lista de entradas de la tabla de
rango creada antes. >l campo varattno da la posi;in del atributo dentro de la relacin.
Si el nombre de un atributo no se consigue encontrar, se devuelve un error # se aborta el
procesado de la consulta.
3.4.4 El sistema de reglas de Postgres
Postgres utiliza un poderoso sistema de reglas para la especificacin de actuali!aciones de vistas
ambiguas. /riginalmente el sistema de reglas de consista en dos implementaciones)
>l primero traba<aba utilizando el procesado a nivel de tupla # se implementaba en el
e"ecutor. >l sistema de reglas se disparaba cada vez que se acceda una tupla individual. >sta
implementacin se retir en 7.CC: cuando la 8ltima versin oficial del pro#ecto Postgres se
transform en PostgresC:.
La segunda imp7ementacin del sistema de reglas es una tcnica llamada reescritura de la
consulta. >l sistema de re escritura es un mdulo que e-iste entre la etapa del traductor # el
planificador/optimi!ador. >st( tcnica contin8a implementada.
>l sistema de reescritura
>l sistema de re escritura de la consulta es un mdulo entre la etapa de traduccin # el
planificador/optimizador. Procesa el (rbol devuelto por la etapa de traduccin %que representa una
consulta de usuario& # si e-iste una regla que deba ser aplicada a la consulta reescribe el (rbol de
una forma alternativa.
3.4.5 Planiicador!optimi"ador
La tarea del planificador/optimi!ador es crear un plan de e<ecucin ptimo. Primero combina todas
las posibles vas de barrer %scannear& # cru!ar .oin& las relaciones que aparecen en una consulta.
Todas las rutas creadas conducen al mismo resultado # es el traba<o del optimizador estimar el
coste de e<ecutar cada una de ellas para encontrar cual es la m(s econmica.
.enerando planes posibles
>l planificador/optimizador decide qu planes deberan generarse bas(ndose en los tipos de ndices
definidos sobre las relaciones que aparecen en una consulta. Siempre e-iste la posibilidad de
realizar un barrido secuencial de una relacin, de modo que siempre se crea un plan que slo utiliza
barridos secuenciales. Se asume que ha# definido un ndice en una relacin %por e<emplo un ndice
!Etree& # una consulta contiene la restriccin relation.attribute OPR constant. Si
relation.attribute acierta a coincidir con la clave del ndice !Etree # /PH es distinto de
'OP' se crea un plan utilizando el ndice !Etree para barrer la relacin. Si ha# otros ndices presentes
# las restricciones de la consulta aciertan con una clave de un ndice, se considerar(n otros planes.
Tras encontrar todos los planes utilizables para revisar relaciones 8nicas, se crean los planes para
cruzar .oin& relaciones. >l planificador/optimizador considera slo cruces entre cada dos relaciones
para los cuales e-iste una cl(usula de cruce correspondiente %es decir, para las cuales e-iste una
restriccin como WHERE rell. attrlre1!. attr!) en la cualificacin de la Q+>H>. Se
generan todos los posibles planes para cada cruce considerado por el planificador/optimizador. Las
tres posibles estrategias son)
Cruce de iteracin anidada %nested iteration <oin&) La relacin derecha se recorre para cada
tupla encontrada en la relacin izquierda. >sta estrategia es f(cil de implementar pero puede
consumir mucho tiempo.
Cruce de ordenacin me!clada %merge sort <oin&) ;ada relacin es ordenada por los
atributos del cruce antes de iniciar el cruce mismo. Gespus se mezclan las dos relaciones
teniendo en cuenta que ambas relaciones est(n ordenadas pro los atributos del cruce. >ste
modelo de cruce es m(s atractivo porque cada relacin debe ser barrida slo una vez.
Cruce inde,ado %hash <oin&) La relacin de la derecha se inde-a primero sobre sus atributos
para el cruce. * continuacin, se barre la relacin izquierda, # los valores apropiados de
cada tupla encontrada se utilizan como clave inde-ada para localizar las tuplas de la relacin
derecha.
;omo se mencion anteriormente, Postgres soporta una variedad de tipos diferentes de datos, e
incluso se pueden utilizar tipos definidos por el usuario. Para ser capaz de mantener la gran cantidad
de funciones # operadores, es necesario almacenarlos en una tabla del sistema. ;ada funcin #
operador toma un identificador de operador 8nico. Ge acuerdo con los tipos de los atributos usados
en las cualificaciones, etc, se utilizan los identificadores de operador apropiados.
3.4.# E$ecutor
>l e"ecutor toma el plan devuelto por el planificador/optimizador # arranca procesando el
nodo superior.
*ntes de poder hacer ninguna mezcla, se deben leer dos tuplas, una de cada subplan. Ge este modo,
el e<ecutor mismo llama recursivamente a procesar los subplanes %arranca con el subplan unido al
"rbol izquierdo&. >l nuevo nodo superior %el nodo superior del subplan izquierdo& es un nodo
SeqScan, # de nuevo se debe tomar una tupla antes de que el nodo mismo pueda procesarse. >l
e<ecutor mismo llama recursivamente otra vez al subplan unido al "rbol i#$uierdo del nodo
SeqScan.
>l nuevo nodo superior es un nodo Sort. ;omo un sort se debe realizar sobre la relacin completa,
el e<ecutor arranca le#endo tuplas desde el subplan del nodo Sort # las ordena en una
relacin temporal %en memoria o en un fichero& cuando se visita por primera vez el nodo Sort.
%Posteriores e-(menes del nodo Sort devolver(n siempre 8nicamente una tupla de la relacin
temporalmente ordenada&.
;ada vez que el procesado del nodo Sort necesita de una nueva tupla, se llama de forma recursiva
al e<ecutor para que trate el nodo Se$Scan unido como subplan. La relacin %a la que se refiere
internamente por el valor dado en el campo scanrelid) se recorre para encontrar la siguiente tupla.
Si la tupla satisface la cualificacin dada por el (rbol unido a $p$ual se da por buena para su
tratamiento, # en otro caso se lee la siguiente tupla hasta la primera que satisfaga la cualificacin. Si se
ha procesado la 8ltima tupla de la relacin, se devuelve un puntero L9LL.
9na vez que se ha recuperado una tupla en el "rbol i#$uierdo del %ruce &e#clado
'&erge(oin) , se procesa del mismo modo el "rbol derec)o. Si se tienen presentes ambas
tuplas, el e<ecutor procesa el ;ruNe &e#clado. Siempre que se necesita una nueva tupla de uno de
los subplanes, se realiza una llamada recursiva al e<ecutor para obtenerla. Si se pudo crear una tupla para
cruzarla, se devuelve # se da por terminado el procesado completo de (rbol del plan.
Se realizan ahora los pasos descritos para cada una de las tuplas, hasta que se devuelve un puntero
L9LL para el procesado del nodo %ruce &e#clado, indicando que hemos terminado.
.. ESTRUCTURA DE LA MEMORIA
PostgreSQLql no hace un manejo de memoria como tal, sino que se apoya en las propiedades del manejo
del Kernel del Sistema Operativo sobre el cual se este ejecutando, sujetndose a las ventajas y desventajas
del mismo.
Casi todos los Sistemas Operativos modernos proveen caractersticas de System V PC (nterProcess
Commucation), la cual se encarga de la comunicacin entre los procesos del System V como lo son: colas
de mensajes, conjuntos de semforos y segmentos de memoria compartida. Debido a que PostgreSQLql
solo hace referencia a estos recursos es casi irrelevante para PostgreSQLql el manejo de los mismos, pero
no todos los Sistemas Operativos tienen estos servicios encendidos o no tienen configurado correctamente
el espacio inicial necesario para el correcto funcionamiento de PostgreSQLql.
Cuando PostgreSQLql excede uno de los lmites de los recursos de PC, entonces el PostMaster (demonio
supervisor de UNX) no se inicializa y habr que tratar el error que se presenta de forma concreta. A
continuacin se muestra una tabla que muestra los parmetros y valores que pueden resolver algunos
problemas comunes.
Nombre Descripcin Valores
SHMMAX Tamao mximo de
segmento de memoria
compartido (bytes)
512 Kb + 8192 * buffers + extra ..
nfinito
SHMMN Tamao mnimo de
segmento de memoria
compartido (bytes)
1 (alrededor de 256 Kb)
SHMSEG Nmero mximo de
segmentos compartidos de
memoria por proceso
Solo un registro es necesario, pero
por default la asignacin es mucho
ms alta
SHMMN Nmero mximo de
segmentos compartidos de
memoria system-wide
Al igual que SHMSEG+espacio para
otras aplicaciones
SEMN Nmero mximo de
identificadores de
semforo
>= ceil(max_conecciones/16)
SEMMNS Nmero mximo de
identificadores de
semforo System-wide
ceil(max_conecciones/16)*17+espacio
para otras aplicaciones
SEMMSL Nmero mximo de
semforos por segmento
>=17
SEMVMX Nmero mximo de
semforos
>=255
El parmetro mas importante acerca de la configuracin de la memoria compartida podra es SHMMAX, que
describe el tamao mximo que puede tener un segmento de memoria compartida. El tamao requerido de
memoria compartida varia, junto con el nmero de buffers requerido, y el nmero de conexiones.
1. M2TODOS DE INTEGRIDAD3 CONCURRENCIA3 CONSISTENCIA Y MANE4O DE
TRANSACCIONES DE DATOS.
1.1. M5!#!" #e Ine6ri#$#
PostgreSQLQL soporta integridad referencial, la cual es utilizada para garantizar la validez de los datos de
la base de datos. es un sistema de reglas que utilizan la mayora de las bases de datos relacionales para
asegurarse que los registros de tablas relacionadas son vlidos y que no se borren o cambien datos
relacionados de forma accidental produciendo errores de integridad.
Cuando se define una columna como clave fornea, las filas de la tabla pueden contener en esa columna o
bien el valor nulo (ningn valor), o bien un valor que existe en la otra tabla, un error sera asignar a un
habitante una poblacin que no est en la tabla de poblaciones. Eso es lo que se denomina integridad
referencial y consiste en que los datos que referencian otros (claves forneas) deben ser correctos. La
integridad referencial hace que el sistema gestor de la base de datos se asegure de que no hayan en las
claves forneas valores que no estn en la tabla principal.
La integridad referencial se activa en cuanto creamos una clave fornea y a partir de ese momento se
comprueba cada vez que se modifiquen datos que puedan alterarla.
1.2. C!n&urren&i$3 C!n"i"en&i$ Y M$ne7! #e r$n"$&&i!ne" #e D$!".
Las bases de datos tradicionales utilizan bloqueos para controlar la concurrencia, esto en posgresql es
diferente, este manejador mantiene la consistencia de datos utilizando el Control de Concurrencia Multi-
Versin (MVCC) . MVCC est considerado mejor que el bloqueo a nivel de fila porque un lector nunca es
bloqueado por un escritor. En su lugar, PostgreSQLQL mantiene una ruta a todas las transacciones
realizadas por los usuarios de la base de datos. PostgreSQLQL es capaz entonces de manejar los registros
sin necesidad de que los usuarios tengan que esperar a que los registros estn disponibles. Este
tratamiento de registros produce que haya un aislamiento de transacciones para cada sesion.
Los bloqueos a nivel de tabla y rengln son permitidos en PostgreSQLQL para aplicaciones que no se
adaptan tan fcilmente al esquema MVCC. Sin embargo el uso correcto de MVCC ofrece mucho mejor
desempeo que los bloqueos.
Para el manejo de transacciones se manejan niveles de aislamiento de transacciones. El estndar de SQL
define cuatro niveles de aislamiento entre transacciones. Tambin define tres tipos de fenmenos que
pueden ocurrir en cada nivel. Estos fenmenos son:
Lectura Sucia:
Una transaccin lee datos escritos por una transaccin que aun no ha terminado
Lectura no repetible:
Una transaccin vuelve a leer datos que ha ledo ya previamente y encuentra que la lectura ha
cambiado, por intervencin de otra transaccin.
Lectura Fantasma :
Una transaccin vuelve a ejecutar un query debido a que otra transaccin hizo cumplir las
condiciones para que se cumplieran las condiciones de ejecucin.
Los cuatro niveles de aislamiento de transacciones y sus riesgos se describen en la siguiente tabla:
Nivel de Aislamiento Lectura Sucia Lectura No repetible Lectura Fantasma
Read uncommitted Posible Posible Posible
Read committed No posible Posible Posible
Repeatable read No posible No posible Posible
Serializable No posible No posible No posible
En PostgreSQLQL, se puede recurrir a cualquiera de los niveles de aislamiento. Pero internamente solo se
manejan dos niveles: Read Commited y Serializable siendo el criterio de uso el siguiente nivel mas estricto
que el seleccionado. La razn por la cual solo se manejan dos niveles de aislamiento es por el manejo de
MVCC en la arquitectura de control de concurrencia. Para establecer el nivel de aislamiento de una
transaccin se utiliza el comando SET TRANSACTON.
Como las consultas en PostgreSQLSQL no bloquean datos, por el manejo de aislamiento de transacciones,
estos datos pueden ser accedidos por otra transaccin que los este manejando, produciendo una confusin
de datos.
Para asegurar la consistencia de datos se debe utilizar la sentencia SELECT FOR UPDATE. Esto asegura
la consistencia de datos cuando se transporte la aplicacin de PostgreSQLQL a otros ambientes. Esto
implica recursos extras sobre MVCC.
8. IMPLEMENTACIN DEL DISE9O CONCEPTUAL
Es una fase delicada porque precede inmediatamente aquella muy importante del anlisis del sistema, para
la cual los objetivos y justificaciones deben haber sido ya definidos. La fase de anlisis del sistema ser, en
prctica, definir la factibilidad y el costo (en trminos de recursos, riesgos, etc.) para la implementacin del
proyecto.
Un esquema conceptual es una descripcin de alto nivel de la estructura de la base de datos,
independientemente del SGBD que se vaya a utilizar para manipularla. Un modelo conceptual es un
lenguaje que se utiliza para describir esquemas conceptuales.
El objetivo del diseo conceptual es describir el contenido de informacin de la base de datos y no las
estructuras de almacenamiento que se necesitarn para manejar esta informacin.
En esta etapa se debe construir un esquema de la informacin que se usa en la empresa,
independientemente de cualquier consideracin fsica. Al construir el esquema, los diseadores descubren
la semntica (significado) de los datos de la empresa: encuentran entidades, atributos y relaciones. El
objetivo es comprender:
La perspectiva que cada usuario tiene de los datos.
La naturaleza de los datos, independientemente de su representacin fsica.
El uso de los datos a travs de las reas de aplicacin.
El esquema conceptual se puede utilizar para que el diseador transmita a la empresa lo que ha entendido
sobre la informacin que sta maneja. Para ello, ambas partes deben estar familiarizadas con la notacin
utilizada en el esquema. La ms popular es la notacin del modelo entidad-relacin.
El esquema conceptual se construye utilizando la informacin que se encuentra en la especificacin de los
requisitos de usuario. El diseo conceptual es completamente independiente de los aspectos de
implementacin, como puede ser el SGBD que se vaya a usar, los programas de aplicacin, los lenguajes
de programacin, el hardware disponible o cualquier otra consideracin fsica. Durante todo el proceso de
desarrollo del esquema conceptual ste se prueba y se valida con los requisitos de los usuarios. El
esquema conceptual es una fuente de informacin para el diseo lgico de la base de datos.
8.1. Me!#!%!6:$ #e% #i"e;! &!n&e)u$%
El primer paso en el diseo de una base de datos es la produccin del esquema conceptual. Normalmente,
se construyen varios esquemas conceptuales, cada uno para representar las distintas visiones que los
usuarios tienen de la informacin. Cada una de estas visiones suelen corresponder a las diferentes reas
funcionales de la empresa como, por ejemplo, produccin, ventas, recursos humanos, etc.
Estas visiones de la informacin, denominadas vistas, se pueden identificar de varias formas. Una opcin
consiste en examinar los diagramas de flujo de datos, que se pueden haber producido previamente, para
identificar cada una de las reas funcionales. La otra opcin consiste en entrevistar a los usuarios, examinar
los procedimientos, los informes y los formularios, y tambin observar el funcionamiento de la empresa.
A los esquemas conceptuales correspondientes a cada vista de usuario se les denomina esquemas
conceptuales locales. Cada uno de estos esquemas se compone de entidades, relaciones, atributos,
dominios de atributos e identificadores. El esquema conceptual tambin tendr una documentacin, que se
ir produciendo durante su desarrollo. Las tareas a realizar en el diseo conceptual son las siguientes:
1. Identificar las entidades: En primer lugar hay que definir los principales objetos que interesan al
usuario. Estos objetos sern las entidades. Una forma de identificar las entidades es examinar las
especificaciones de requisitos de usuario. En estas especificaciones se buscan los nombres o los
sintagmas nominales que se mencionan (por ejemplo: nmero de empleado, nombre de empleado,
nmero de inmueble, direccin del inmueble, alquiler, nmero de habitaciones).
2. Identificar las relaciones: Una vez definidas las entidades, se deben definir las relaciones existentes
entre ellas. Del mismo modo que para identificar las entidades se buscaban nombres en las
especificaciones de requisitos, para identificar las relaciones se suelen buscar las expresiones
verbales (por ejemplo: oficina tiene empleados, empleado gestiona inmueble, cliente visita
inmueble). Si las especificaciones de requisitos reflejan estas relaciones es porque son importantes
para la empresa y, por lo tanto, se deben reflejar en el esquema conceptual.
3. Identificar los atributos y asociarlos a entidades y relaciones: Al igual que con las entidades, se
buscan nombres en las especificaciones de requisitos. Son atributos los nombres que identifican
propiedades, cualidades, identificadores o caractersticas de entidades o relaciones. Al identificar
los atributos, hay que tener en cuenta si son simples o compuestos. Por ejemplo, el atributo
direccin puede ser simple, teniendo la direccin completa como un solo valor: `San Rafael 45,
Almazora'; o puede ser un atributo compuesto, formado por la calle (`San Rafael'), el nmero (`45') y
la poblacin (`Almazora'). Tambin se deben identificar los atributos derivados o calculados, que
son aquellos cuyo valor se puede calcular a partir de los valores de otros atributos. Por ejemplo, el
nmero de empleados de cada oficina, la edad de los empleados o el nmero de inmuebles que
gestiona cada empleado. Conforme se van identificando los atributos, se les asignan nombres que
tengan significado para el usuario. De cada atributo se debe anotar la siguiente informacin:
Nombre y descripcin del atributo.
Alias o sinnimos por los que se conoce al atributo.
Tipo de dato y longitud.
Valores por defecto del atributo (si se especifican).
Si el atributo siempre va a tener un valor (si admite o no nulos).
Si el atributo es compuesto y, en su caso, qu atributos simples lo forman.
Si el atributo es derivado y, en su caso, cmo se calcula su valor.
Si el atributo es multi valuado.
4. Determinar los dominios de los atributos: El dominio de un atributo es el conjunto de valores que
puede tomar el atributo. Por ejemplo el dominio de los nmeros de oficina son las tiras de hasta tres
caracteres en donde el primero es una letra y el siguiente o los dos siguientes son dgitos en el
rango de 1 a 99; el dominio de los nmeros de telfono y los nmeros de fax son las tiras de 9
dgitos.
5. Determinar los identificadores: Cada entidad tiene al menos un identificador. En este paso, se trata
de encontrar todos los identificadores de cada una de las entidades. Los identificadores pueden ser
simples o compuestos. De cada entidad se escoger uno de los identificadores como clave primaria
en la fase del diseo lgico.
6. Determinar las jerarquas de generalizacin (si las hay): En este paso hay que observar las
entidades que se han identificado hasta el momento. Hay que ver si es necesario reflejar las
diferencias entre distintas ocurrencias de una entidad, con lo que surgirn nuevas sub-entidades de
esta entidad genrica; o bien, si hay entidades que tienen caractersticas en comn y que realmente
son sub-entidades de una nueva entidad genrica.
7. Dibujar el diagrama entidad-relacin: Una vez identificados todos los conceptos, se puede dibujar el
diagrama entidad-relacin correspondiente a una de las vistas de los usuarios. Se obtiene as un
esquema conceptual local.
8. Reisar el esquema conce!tual local con el usuario: Antes de dar por finalizada la fase del diseo
conceptual, se debe revisar el esquema conceptual local con el usuario. Este esquema est
formado por el diagrama entidad-relacin y toda la documentacin que describe el esquema. Si se
encuentra alguna anomala, hay que corregirla haciendo los cambios oportunos, por lo que
posiblemente haya que repetir alguno de los pasos anteriores. Este proceso debe repetirse hasta
que se est seguro de que el esquema conceptual es una fiel representacin de la parte de la
empresa que se est tratando de modelar.
8.2. Di"e;! C!n&e)u$% P!"6reSQLQL
PostgreSQLQL requiere de cierto conocimiento del lenguaje SQL. Existen diferentes herramientas que nos
pueden ayudar en la creacin del diseo conceptual:
Erwin
FERRET
EMS PostgreSQ*$l &anage
DB Designer (http://www.fabforce.net/downloads.php)
<. ADMINISTRACIN DE LA SEGURIDAD DE LA +ASE DE DATOS.
<.1. Re")$%#! = re&u)er$&i'n #e #$!".
Siempre se debe de respaldar regularmente las bases de datos, ya que no se debe de confiar en los
sistemas de copia de seguridad del sistema para la copia de respaldos, ya que no garantiza su consistencia
para un uso posterior.
PostgreSQLQL provee de 3 mecanismos para el respaldo y recuperacin de bases de datos: pg_dump,
pg_dumpall, y pg_restore
El mecanismo ms fcil de usar para respaldar una base de datos es pg_dump que redirecciona la salida a
un archivo de la siguiente manera:
$ pg_dump bpfinal > bpfinal.backup
El esquema de respaldo produce un script que al ejecutarse, generara la creacin de usuarios y sus
privilegios, creara las tablas e insertara datos.
Para restaurar una base de datos respaldada necesitamos ejecutar el script para crear las tablas, pero
primero debemos crear la base de datos donde restauraremos y despus ejecutar el script. Asumiendo que
tenemos una base de datos vaca llamada ne"b!fina# despus podemos restaurar los datos de la original
usando psql para ejecutar el script del respaldo:
$ createdb newbpfinal
$ psql f bpfinal.backup newbpfinal
Para hacer un respaldo de la base de datos completa, incluyendo las tablas internas de sistema usadas por
PostgreSQLQL, es usando pg_dumpall como un sper usuario de la base de datos.
$ su PostgreSQL
$ pg_dumpall > all.backup
Para restaurar el respaldo completamente, solamente necesitamos conectarnos a la base de datos, y
nuestro respaldo contiene las instrucciones para crear cada base de datos, lo nico que necesitamos para
recuperar la informacin es tener los permisos suficientes para leer y escribir todos los datos:
$ psql f all.backup template1
Tenemos la posibilidad de comprimir el respaldo utilizando el programa de compresin gzip:
$ pg_dump bpfinal | gzip > bpfinal.backup.gz
$ gunzip c bpfinal.backup.gz | psql newbpfinal.
La sintaxis de la instruccin pg_dump es
Pg_dump [dbname] [options...]
Entre los argumentos que podemos usar con la instruccin pg_dump estn:
- h host Es el servidor a conectarse, por default es la maquina local.
- p port - Es el puerto a conectarse, por default PostgreSQLQL utiliza el 5432.
- t table Especifica una tabla a respaldar.
- u - Usa un password para autentificarse.
- v - Modo de verbo.
- S user Especifica el sper usuario de la base de datos para ejecutar triggers.
- c - Limpia. Se usa para hacer drop a las tablas para despus crear unas nuevas.
- C - Crear. Se utiliza para crear la base de datos.
- a - nicamente respalda los datos
- s - nicamente respalda la estructura.
- x - Suprime en el respaldo el control de acceso (Comandos GRANT y REVOKE).
- b - Respalda un objeto muy grande.
- O - No coloca los dueos de los objetos de la base de datos original.
- f file - Escribe el respaldo en el archivo especificado.
- F format Especifica el formato del respaldo que pueden ser:
p En un archivo de texto plano (por default)
t en un archivo comprimido (tar)
c en un archivo personalizado por el usuario.
- Z 0 ..9- Para el archivo personalizado, indica el nivel de compresin, 0 menor a 9 mayor.
Los respaldos con formato (- F t y F c) ofrecen mas flexibilidad para restaurar la base de datos. Para
restaurar usando un archivo, utilizamos pg_restore, cuya sintaxis es:
pg_restore [archivo] [options...]
Entre sus parmetros tenemos:
- h host Es el servidor a conectarse, por default es la maquina local.
- p port - Es el puerto a conectarse, por default PostgreSQLQL utiliza el 5432.
- d dname Se conecta directamente a la BD especificada. Los objetos grandes(BLOBs)
nicamente se pueden restaurar de esta forma.
- t table - Especifica una tabla a restaurar.
- P proc- Especifica una funcin (stored procedure) a restaurar.
- T trig - Especifica un trigger a restaurar.
- ndex Especifica un ndice a restaurar.
- u - Especifica un usuario para autentificarse.
- v - Del modo verbo.
- l - Lista el contenido de un archivo, usable con U
- U file - Restaura solo los elementos de la Basse de datos listados en el archivo.
- S user- Especifica el usuario para colocar el dueo de los triggers.
- c - Hace drop a los objetos antes de crearlos.
- a - Restaura solo los datos.
- s - Restaura solo la estructura.
- x - Suprime las instrucciones de control de accesos (GRANT y REVOKE).
- O - No coloca el dueo de los objetos que tiene en la base de datos original.
- f file - Lee el respaldo de un archivo en especifico.
Para respaldar y restaurar bajo un nuevo nombre, podemos usar la siguiente secuencia de comandos:
$ dg_dump F c bpsimple > bpsimple.bak
$ createdb bpsimple2
$ pg_restore d bpsimple2 bpsimple.bak.
<.2. Se6uri#$# #e >$"e #e #$!".
Las aplicaciones de base de datos requieren seguridad, ya que no queremos que nuestra informacin sea
accesible a cualquier aplicacin o persona, por lo que debemos tener un control de accesos, para lo cual
usamos las instrucciones GRANT y REVOKE.
PostgreSQLQL protege la base de datos de forma que solo los usuarios de PostgreSQLQL puedan acceder
a los datos, el nico que puede ver los archivos desde el sistema operativo es el DBA.
PostgreSQLQL utiliza distintos modos de autentificacin de usuarios y los puede configurar para cada
direccin que se conecte a la base de datos:
Mtodo de autentificacin Descripcin
trust Siempre se podr conectar
password Pide un password y lo compara con uno de la tabla de entrada
pg_shadow.
Crypt Usa un password de autentificacin, pero el password es
encriptado.
dent El cliente identifica si el servidor usa autentificacin.
Krb4 La autentificacin se hace usando Kerberos versin 4.
Krb5 La autentificacin se hace usando Kerberos versin 5.
Reject La conexin siempre se niega.
La configuracin de la seguridad es hecha usando el archivo pg_hba.conf en el directorio de datos de
PosgreSQL. El archivo contiene la estructura de la estructura de la autentificacin, este se utiliza solo para
la autentificacin bsica.
En el archivo pg_hba.conf contiene un registro por lnea, las lneas en blanco son ignoradas, cada registro
especifica un tipo de autentificacin en particular, se utiliza un mtodo por cada maquina que se conecte o
cada direccin de la red.
Una conexin local tiene la siguiente forma:
Local database method [argument]
?. ADMINISTRACIN DE O+4ETOS @USUARIOS3 TA+LAS3 VISTAS3
PROCEDIMIENTOS ALMACENADOS3 FUNCIONES3 REGLAS3 ETC.A
?.1. T$>%$"
Estas son las tablas que PostgreSQL utiliza como catlogos para mantener el sistema. Es en base a la idea
de mantener todo en tablas, a diferencia de otros manejadores de bases de datos, es extensible.
?.1.1. C$B%!6! #e% "i"em$ P!"6reSQLQL.
Cada base de datos tiene estas mismas tablas, salvo por la primera que es nica, que almacenan cada una
de las partes que componen la base de datos.
N!m>re #e% &$B%!6! De"&ri)&i'n
pg_database Bases de datos
pg_class Clases o tables
pg_attribute Atributos o campos de la clase o tabla
pg_index ndices secundarios
pg_proc Procedimientos (en C y en SQL)
pg_type Tipos de datos (del sistema y definidos por el usuario)
pg_operator Operadores (del sistema y definidos por el usuario)
pg_aggregate Agregados y funciones agregadas
pg_am Mtodos de acceso
pg_amop Operadores de mtodos de acceso
pg_amproc Funciones de soporte para mtodos de acceso
pg_opclass Clases de operadores de mtodos de acceso
?.1.2. T$>%$ que &!niene !#$" %$" >$"e" #e #$!" que e,i"en en e% "i"em$.
T$>%e C )6D#$$>$"e
Fie%# T=)e Len6/ De"&ri)i!n
datname name 32 Nombre de la base
datdba int4 4 Uid del dababase admin
datpath text var El path para llegar hasta la base
?.1.*. T$>%$ que &!niene !#$" %$" $>%$" en %$ >$"e #e #$!" $&u$%.
Table = pg_class
Fie%# T=)e Len6/ De"&ri)i!n
relname name 32 Nombre de la tabla
reltype oid 4 El Object d de la tabla
relowner oid 4 El UD (PostgreSQL) del dueo de la tabla
relam oid 4
relpages int4 4 Nmero de pginas ocupadas por la tabla
reltuples int4 4 Nmero de tuplas en la tabla
relhasindex bool 1 Verdadero si tiene al menos un ndice
relisshared bool 1
relkind char 1
relnatts int2 2 Nmero de atributos
relchecks int2 2
reltriggers int2 2 Nmero de triggers asociados
relhasrules bool 1 Verdadero si tiene reglas asociadas
relacl aclitem[] var
?.1... T$>%$ que &!niene %!" $ri>u!" #e %!" $ri>u!" #e !#$" %$" $>%$" en %$ >$"e $&u$%.
T$>%e C )6D$ri>ue
Fie%# T=)e Len6/ De"&ri)i!n
attrelid oid 4 OD del atributo
attname name 32 Nombre del atributo
atttypid oid 4 Oid del tipo definido para el atributo
attdisbursion float4 4
attlen int2 2 Longitud en bytes del atributo
attnum int2 2
attnelems int4 4
attcacheoff int4 4
atttypmod int2 2
attbyval bool 1
attisset bool 1
attalign char 1
attnotnull bool 1
atthasdef bool 1
?.2. Fun&i!ne"
PostgreSQL proporciona tres tipos de funciones:
Funciones de lenguaje de consultas (funciones escritas en SQL)
Funciones de lenguaje procedural (funciones escritas en: PLTCL o PLSQL)
Funciones de lenguaje de programacin (funciones escritas en un lenguaje de programacin
compilado tales como C)
Cada clase de funcin puede tomar un tipo base, un tipo compuesto o alguna combinacin como
argumentos (parmetros). Cada clase de funcin puede devolver un tipo base o un tipo compuesto.
?.2.1. Fun&i!ne" #e %en6u$7e #e &!n"u%$" @SQLA
Las funciones SQL ejecutan una lista arbitraria de consultas SQL, devolviendo los resultados de la ltima
consulta de la lista. Las funciones SQL en general devuelven conjuntos. Si su tipo de retorno no se
especifica como un seto+, entonces un elemento arbitrario del resultado de la ltima consulta ser
devuelto.
El cuerpo de una funcin SQL que sigue a AS debera ser una lista de consultas separadas por caracteres
espacio en blanco y entre parntesis dentro de comillas simples. Notar que las comillas simples usadas en
las consultas se deben escribir como smbolos de escape, precedindolas con dos barras invertidas.
Los argumentos de la funcin SQL se pueden referenciar en las consultas usando una sintaxis $n: $1 se
refiere al primer argumento, $2 al segundo, y as sucesivamente. Si un argumento es complejo, entonces
una notacin dot (por ejemplo "$1.emp") se puede usar para acceder a las propiedades o atributos del
argumento o para llamar a funciones.
?.2.2. Fun&i!ne" #e %en6u$7e )r!&e#ur$%.
Como tal NO estn construidos dentro de PostgreSQL. Se proporcionan como mdulos cargables. Hay dos
lenguajes procedurales disponibles con la distribucin estndar de PostgreSQL (PLTCL y PLSQL), y otros
lenguajes se pueden definir.
?.2.*. Fun&i!ne" inern$".
Las funciones internas son funciones escritas en C que han sido enlazadas estticamente en el proceso
backend de PostgreSQL. La clusula da el nombre en lenguaje C de la funcin, que no necesita ser el
mismo que el nombre que se declara para el uso de SQL. (Por razones de compatibilidad con versiones
anteriores, una cadena AS vaca se acepta con el significado de que el nombre de la funcin en lenguaje C
es el mismo que el nombre en SQL.) Normalmente, todas las funciones internas presentes en el backend se
declaran como funciones SQL durante la inicializacin de la base de datos, pero un usuario podra usar
CREATE FUNCTION para crear nombres de alias adicionales para una funcin interna.
?.2... Fun&i!ne" #e Len6u$7e C!m)i%$#! @CA
Las funciones escritas en C se pueden compilar en objetos que se pueden cargar de forma dinmica y usar
para implementar funciones SQL definidas por el usuario. La primera vez que la funcin definida por el
usuario es llamada dentro del backend, el cargador dinmico carga el cdigo objeto de la funcin en
memoria, y enlaza la funcin con el ejecutable en ejecucin de PostgreSQL. La sintaxis SQL para CREATE
FUNCTION enlaza la funcin SQL a la funcin en cdigo C de una de dos formas. Si la funcin SQL tiene el
mismo nombre que la funcin en cdigo C se usa la primera forma. El argumento cadena en la clusula AS
es el nombre de camino (pathname) completo del archivo que contiene el objeto compilado que se puede
cargar de forma dinmica. Si el nombre de la funcin C es diferente del nombre deseado de la funcin SQL,
entonces se usa la segunda forma. En esta forma la clusula AS toma dos argumentos cadena, el primero
es el nombre del camino completo del archivo objeto que se puede cargar de forma dinmica, y el segundo
es el smbolo de enlace que el cargador dinmico debera buscar. Este smbolo de enlace es solo el nombre
de funcin en el cdigo fuente C. Despus de que se use por primera vez, una funcin de usuario
dinmicamente cargada, se retiene en memoria, y futuras llamadas a la funcin solo incurren en la pequea
sobrecarga de una bsqueda de tabla de smbolos
?.*. Re6%$"
El sistema de reglas en PostgreSQLQL consiste en modificar las consultas de acuerdo a reglas
almacenadas como parte de la base de datos. Dichas consultas modificadas son pasadas, en orden, al
optimizador, planificador y finalmente al ejecutor. Esto es a diferencia de otros DBMS que simplemente
implementan los sistemas de reglas como procedimientos y triggers almacenados. Este sistema es muy
poderoso y puede ser empleado para procedimientos, vistas y versiones.
Para comprender cmo funciona el sistema de reglas, es necesario saber cuando es invocado y cules son
las entradas que recibe y los resultados que arroja.
El sistema de reglas se haya entre el reconocedor sintctico de consultas y el optimizador. Toma la salida
del reconocedor, un rbol de consultas, y reescribe las reglas de acuerdo al catlogo pg,re-rite, donde
se encuentran las reglas ya en formato de rbol de consulta con alguna informacin extra y produce cero o
ms rboles de consulta como resultado. De esta manera, tanto la entrada como la salida es fcilmente
representable como una asercin SQL.
Los rboles de consultas son una representacin interna de una asercin SQL donde las partes individuales
que lo componen son almacenadas independientemente. Estos rboles de consulta son visibles desde psql
al iniciar el servidor de PostgreSQLQL con la bandera de debug en nivel cuatro. Las reglas en pg_rewrite
estn escritas en el mismo formato, an cuando no son presentadas como la salida de depuracin descrita.
El sistema de reglas de reescritura de queries es totalmente diferente a los procedimientos almacenados y
los triggers. l modifica los queries para tomar en consideracin las reglas y entonces pasa el query
modificado al optimizador para su ejecucin. Es muy poderoso y puede utilizarse de muchas formas, tales
como procedimientos, vistas y versiones del lenguaje de query.
%.4. &istas
Una de las aplicaciones inmediatas del sistema de reglas es la implementacin de vistas en PostgreSQL,
que es realizado por el propio sistema. Es decir, las vistas en PostgreSQLQL estn implementadas con el
sistema de reglas. De hecho, las dos aserciones no son diferentes para PostgreSQLQL:
%RE./E 01EW mivista .S SE*E%/ 2 3RO& mitabla4
expresin valida en PostgreSQLQL, pero que se convierte en:
%RE./E /.5*E mivista 'misma lista de atributos $ue para mitabla)4
%RE./E R6*E 7,RE/mivista7 .S O8 SE*E%/ /O mivista 9O 18S/E.9
SE*E%/ 2 3RO& mitabla4
Porque eso es precisamente lo que internamente hace el comando %RE./E 01EW. Sin embargo, esto
presenta algunos efectos colaterales. Uno de ellos es que la informacin acerca de la vista en los catlogos
del sistema es exactamente la misma que para la tabla. As, para el reconocedor sintctico de consultas, no
hay ninguna diferencia entre una tabla y una vista, ambas son relaciones.
Los beneficios de implementar las vistas con el sistema de reglas estn en que el optimizados tiene toda la
informacin sobre qu tablas tienen que ser revisadas, ms las relaciones entre estas tablas, ms las
cualificaciones restrictivas a partir de la definicin de las vistas, ms las cualificaciones del query original,
todo en un nico rbol de traduccin. Y esta es tambin la situacin cuando el query original es ya una join
entre vistas. Ahora el optimizador debe decidir cul es la mejor ruta para ejecutar el query. Cuanta ms
informacin tenga el optimizador, mejor ser la decisin. Y la forma en que se implementa el sistema de
reglas en PostgreSQL asegura que toda la informacin sobre el query est utilizable.
1E. UTILERFAS DEL RD+MS
1E.1. P!"6reSQLQL C%ien A))%i&$i!n".
Estas aplicaciones y utileras las puede ejecutar el administrador de la Base datos, aunque algunos de ellos
requieren ms privilegios.
clusterdb Hace un cluster de bases de datos de PostgreSQLQL.
createdb Crea una nueva base de datos de PostgreSQLQL
createlang Define un lenguaje procedural nuevo.
createuser Define una cuenta de usuario.
dropdb Borra una Base de datos.
droplang Borra un lenguaje procedural.
dropuser Borra una cuenta de usuario
pg_config Muestra la versin instalada de PostgreSQLQL.
pg_dump -- Extrae una base de datos y la coloca en un archivo.
pg_dumpall Extrae la base de datos en un archivo script.
pg_restore -- restaura la base de datos previamente respaldada por el pg_dump, la cual se
encuentra en un archivo.
psql -- Es una terminal con la que se interactua con el manejador.
vacuumdb recolecta y analiza la informacin no necesaria de una base de datos.
1E.2. P!"6reSQLQL Ser0er A))%i&$i!n"
Estas utileras pueden ser ejecutadas correctamente solo en la mquina donde reside la base de datos.
(localhost)
initdb Crea un nuevo cluster de Base de datos
ipcclean remueve la memoria compartida y los semforos de un servidor de PostgreSQLQL que
fall.
pg_controldata Despliega la informacin de control
pg_ctl Levanta, Detiene o Reinicia el servidor PostgreSQLQL
pg_resetxlog Reinicia las bitacoras y la informacin de control del manejador.
PostgreSQL Ejecuta el servidor PostgreSQLQL en modo single-user.
postmaster Es el Servidor de bases de datos multiusuario.
1E.*. P6A#min
11. DESCRIPCIN DE LOS FRONTENDS Y +ACGENDS CON LOS QUE PUEDE
INTERACTUAR @men&i!n$r %!" que "!n n$i0!" en &$"! #e Fr!nen#A.
Los Backends con los que PostgreSQLql permite interactuar se relacionan directamente al Sistema
Operativo sobre el que se esta trabajando. PostgreSQLQL da soporte a los siguientes S.O. :
GNU/Linux (Cualquier distribucin)
UNX (AX, BSD, HP-UX, SG RS, Mac OS X, Solares, SunOS, Tru64)
BeOS
Todos los anteriores a travs de los llamados DECS, que son configuraciones directas al servidor en el cual
esta contenido el RDBMS.
Windows (de forma nativa desde la v8.0)
Por medio de ODBC, propia del Sistema Operativo, con una configuracin especial.
Se han desarrollado FrontEnds para el manejo de PostgreSQLQL, debido a que este manejador es open
source, los frontends con los que se puede manejar son muchos, he aqu los ms representativos:
PgAcces (Nativo)
nterfaz en Tcl/Tk para realizar consultas y administrar varias bases de datos de froma muy sencilla,
ya que proporciona un ambiente grafico.
PgAdmin
nterfaz grfica para administrar bases de datos que utiliza para su conexin la librera de C: lipq
PHPpgAdmin
Administrador de Base de Datos con interfaz web desarrollado en el lenguaje interpretado PHP.
Psql
Monitor interactivo estandar de PostgreSQLQL basado en lneas de comando.
Ejemplo de lnea de conexin:
$ psql h <host> -d <mi_bd> -u
Acces
Administrador de Base de Datos propio de un nivel de Windows muy bsico, es el ejemplo mas
representativo para manejar la conexin ODBC.
Esquema de Conexin
Frontend enva peticin de conexin a servidor.
Si acepta el pedido, crea un servicio exclusivo para el cliente denominado Backend.
Luego la conexin de realiza directamente con el Backend.
12. MOSTRAR UN E4EMPLO PRHCTICO DE UNA APLICACIN.
1*. CMO ESTA COMPUESTO SU LENGUA4E DE PROGARMACIN NATIVO CON
E4EMPLOS PRHCTICOS.
El lenguaje PL/pgSQL es estructura en bloques. Todas las palabras clave y los identificadores pueden
escribirse mezclando letras maysculas y minsculas.
Un bloque se defiende de la siguiente manera:
[<<label>>]
[DECLARE
declaraciones]
BEGN
sentencias
END;
Pueden existir varios bloques o sub-bloques en la seccin de sentencias de un bloque. Los sub-bloques
pueden ser usados para ocultar las variables a los bloques ms externos. Normalmente una de las
sentencias es el valor de retorno, usando la palabra clave RETURN.
Las variables declaradas en la seccin que antecede a un bloque se inicializan a su valor por omisin cada
vez que se entra al bloque, no solamente al ser llamada la funcin. Por ejemplo:
CREATE FUNCTON estafunc() RETURNS NTEGER AS '
DECLARE
cantidad NTEGER := 30;
BEGN
RASE NOTCE ''Cantidad contiene aqu %'',cantidad;
-- Cantidad contiene aqu 30
cantidad := 50;
--
-- Creamos un sub-bloque
--
DECLARE
cantidad NTEGER := 80;
BEGN
RASE NOTCE ''Cantidad contiene aqu %'',cantidad;
-- Cantidad contiene aqu 80
END;
RASE NOTCE ''Cantidad contiene aqu%'',cantidad;
-- Cantidad contiene aqu 50
RETURN cntidad;
END;
' LANGUAGE 'plpgsql';
No se debe confundir el uso de las sentencias de agrupamiento BEGN/END de PL/pgSQL con los
comandos de la base de datos que sirven para el control de las transacciones. Las funciones y
procedimientos disparadores no pueden iniciar o realizar transacciones y PostgreSQL no soporta
transacciones anidadas.
1*.1 C!men$ri!"
Existen dos tipo de comentarios en PL/pgSQL:
Un doble guin da inicio a un comentario, el cual se extiende hasta el final de la lnea.
Un /* inicia un bloque que se extiende hasta la primera ocurrencia de */.
1*.2 V$ri$>%e" = &!n"$ne"
Todas las variables, filas y registros usados en un bloque o en sus sub-bloques deben declararse en la
seccin de declaraciones del bloque. La excepcin es la variable de un ciclo FOR que itera sobre un rango
de valores enteros.
Las variables en PL/pgSQL pueden ser de cualquier tipo de datos de SQL como NTEGER, VARCHAR y
CHAR. El valor por omisin de todas las variables es el valor NULL de SQL. Ejemplos de declaracin de
variables:
user_id NTEGER;
quantity NUMBER(5);
url VARCHAR;
1*.2.1 C!n"$ne" = 0$ri$>%e" &!n 0$%!re" )!r !mi"i'n
La declaraciones tienen las siguiente sintaxis:
nombre [ CONSTANT ] tipo [ NOT NULL ] [ { DEFAULT | := } valor ];
El valor de una variable declarado como CONSTANT no puede ser modificado. Si acaso se especifica NOT
NULL, la asignacin de un valor NULL causa en un error en tiempo de ejecucin. Puesto que el valor por
omisin de todas las variables es el valor NULL de SQL, todas las variables declaradas como NOT NULL
deben contar con un valor por omisin especfico.
EL valor se evala cada vez que se llama la funcin, as que asignar now a una variable de tipo timestamp
causa que la variables almacene el tiempo real de la llamada a la funcin, no el de la hora en que se
compil en bytecode. Ejemplos:
cantidad NTEGER := 32;
url varchar := ''http://misitio.com'';
user_id CONSTANT NTEGER := 10;
1*.2.2 V$ri$>%e" )$"$#$" $ %$" (un&i!ne"
Las variables que se pasan a las funciones son denominadas con los identificadores $1, $2, etc. (el mximo
es 16). Algunos ejemplos:
CREATE FUNCTON iva_venta(REAL) RETURNS REAL AS '
DECLARE
subtotal ALAS FOR $1;
BEGN
return subtotal * 1.15;
END;
' LANGUAGE 'plpgsql';
CREATE FUNCTON instr(VARCHAR,NTEGER) RETURNS NTEGER AS '
DECLARE
v_string ALAS FOR $1;
index ALAS FOR $2;
BEGN
-- Algunos clculos iran aqu
END;
' LANGUAGE 'plpgsql';
1*.*. Ari>u!"
Usando los atributos %TYPE and%ROWTYPE, es posible declarar variables con el mismo tipo de dato o
estructura de otro item de la base de datos (por ejemplo, un campo de una tabla).
%TYPE Proporciona el tipo de dato de una variable o una columna. Se puede utilizar para declarar variables
que almacenen valores de bases de datos. Por ejemplo: Si tenemos una columna llamada user id en la tabla
users.
Para declarar una variable con el mismo tipo de dato que el usado en nuestra tabla de usuarios, lo que hara
es:
user_id users.user_id\%TYPE;
Al usar%TYPE puede despreocuparse de los cambios futuros en la definicin de la tabla.
nombre tabla%ROWTYPE Declara una rengln con la estructura de la tabla especificada. tabla
puede ser una tabla o una vista que exista en la base de datos. Los campos del rengln se accesan con
la notacin punto.
Los parmetros de una funcin pueden ser de tipo compuesto (renglones completos de una tabla). Es este
caso, el identificador correspondiente $n ser del tipo rowtype, pero debe usarse un seudnimo o alias
usando el comando ALAS que se describe ms adelante. Solamente los atributos del usuario de la tabla
pueden ser accesibles en el rengln, ni los OD ni otros atributos del sistema (debido a que el rengln puede
ser de una vista). Los campos de un rowtype heredan los tamaos de los campos o la precisin de los tipos
de dato para char(), etc.
DECLARE
users_rec users%ROWTYPE;
user_id users%TYPE;
BEGN
user_id := users_rec.user_id;
...
create function cs_refresh_one_mv(integer) returns integer as '
DECLARE
key ALAS FOR $1;
table_data cs_materialized_views\%ROWTYPE;
BEGN
SELECT NTO table_data * FROM cs_materialized_views
WHERE sort_key=key;
F NOT FOUND THEN
RASE EXCEPTON ''View '' || key || '' not found'';
RETURN 0;
END F;
-- La columna mv_name de cs_materialized_views almacena
-- los nombres de las vistas.
TRUNCATE TABLE table_data.mv_name;
NSERT NTO table_data.mv_name || '' '' || table_data.mv\query;
return 1;
end;
' LANGUAGE 'plpgsql';
1*... E,)re"i!ne"
Todas las expresiones usadas en las sentencias de PL/pgSQL son procesadas usando el ejecutor del
bac$end. Las expresiones que parecen contener constantes pueden requerir de una evaluacin en tiempo
de ejecucin (por ejemplo, now para el tipo de dato timestamp) as que es imposible para el analizador
sintctico (!arser) de PL/pgSQL identificar los valores de las constantes reales diferentes de NULL. Todas
las expresiones son evaluadas internamente ejecutando una sentencia SELECT expresin usando el gestor
de SP. En la expresin, las ocurrencias de los identificadores
de las variables se sustituyen por parmetros y los valores reales de las variables se pasan al ejecutor en el
arreglo de parmetros. Todas las expresiones usadas en una funcin de PL/pgSQL son preparadas y
almacenadas solamente una vez.
La nica excepcin a esta regla es una sentencia EXECUTE si se requiere analizar una consulta cada vez
que es encontrada.
La revisin del tipo realizada por el analizador sintctico principal de PostgreSQL tiene algunos efectos
secundarios a la interpretacin de valores constantes.
En detalle, existe una diferencia entre lo que hacen estas dos funciones:
CREATE FUNCTON logfunc1 (text) RETURNS timestamp AS '
DECLARE
logtxt ALAS FOR $1;
BEGN
NSERT NTO logtable VALUES (logtxt, ''now'');
RETURN ''now'';
END;
' LANGUAGE 'plpgsql';
y
CREATE FUNCTON logfunc2 (text) RETURNS timestamp AS '
DECLARE
logtxt ALAS FOR $1;
curtime timestamp;
BEGN
curtime := ''now'';
NSERT NTO logtable VALUES (logtxt, curtime);
RETURN curtime;
END;
' LANGUAGE 'plpgsql';
En el caso de logfunc1(), el analizador principal de PostgreSQL conoce, al preparar el plan para el NSERT,
que la cadena 'now' debe ser interpretada como timestamp debido a que el campo destino de logtable es de
ese tipo. As, crear una constante a partir de ella en ese momento, y la usaren cada una de las
invocaciones de logfunc1(), mientras est vivo el bac$end. Es claro que esto no es lo que esperara el
programador. En el caso de logfunc2(), el analizador principal de PostgreSQL no sabe que tipo debe tener
'now', y por eso regresa un tipo de datos de texto, el cual contiene la cadena 'now'. Durante la asignacin a
la variable local curtime, el intrprete de PL/pgSQL cambia esta cadena a un tipo de timestamp por medio
de una llamada a las funciones text out() and timestamp in() para efectuar la conversin.
1*. 1. Senen&i$"
Cualquier cosa no comprendida por el analizador PL/pgSQL tal como se especifica adelante ser enviado al
gestor de la base de datos, para su ejecucin. La consulta resultante no devolver ningn dato.
1*.1.1 A"i6n$&i'n
Una asignacin de un valor a una variable o campo de fila o de registro se escribe:
identifier := expression;
Si el tipo de dato resultante de la expresin no coincide con el tipo de dato de las variables, o la variable
tienen un tamao o precisin conocido (como char(29)), el resultado ser amoldado implcitamente por el
interprete de bytecode de PL/pgSQL, usando los tipos de las variables para las funciones de entrada y los
tipos resultantes en las funciones de salida. Ntese que esto puede potencialmente producir errores de
ejecucin generados por los tipos de las funciones de entrada. Una asignacin de una seleccin completa
en un registro o fila puede hacerse
del siguiente modo:
SELECT expressions NTO target FROM ...;
target puede ser un registro, una variable de fila o una lista separada por comas de variables y campo de de
registros o filas. Si una fila o una lista de variables se usa como objetivo, los valores seleccionados han de
coincidir exactamente con la estructura de los objetivos o se producir un error de ejecucin. La palabra
clave FROM puede preceder a cualquier calificador vlido, agrupacin, ordenacin, etc. que pueda pasarse
a una sentencia SELECT.
Existe una variable especial llamada FOUND de tipo booleano, que puede usarse inmediatamente despus
de SELECT NTO para comprobar si una asignacin ha tenido xito.
SELECT * NTO myrec FROM EMP WHERE empname = myname;
F NOT FOUND THEN
RASE EXCEPTON ''employee % not found'', myname;
END F;
Si la seleccin devuelve mltiples filas, solo la primera se mueve a los campos objetivo; todas las dems se
descartan.
1*. I. E"ru&ur$" #e &!nr!% #e (%u7!

1*.I.1 C!n#i&i!ne"
F expression THEN
statements
[ELSE
statements]
END F;
La expresin debe devolver un valor que al menos pueda ser adaptado en un tipo booleano.
1*.I.2 +u&%e"
Hay varios tipos de bucles.
[<<label>>]
LOOP
statements
END LOOP;
Se trata de un bucle no condicional que ha de ser terminado de forma explicita, mediante una sentencia
EXT. La etiqueta opcional puede ser usado por las sentencias EXT de otros bucles anidados, para
especificar el nivel del bucle que ha de terminarse.
[<<label>>]
WHLE expression LOOP
statements
END LOOP;
Se trata de un lazo condicional que se ejecuta mientras la evaluacin de expresin sea cierta.
[<<label>>]
FOR name N [ REVERSE ]
express .. expression LOOP
statements
END LOOP;
Se trata de un bucle que se itera sobre un rango de valores enteros. La variable name se crea
automticamente con el tipo entero, y existe solo dentro del bucle. Las dos expresiones dan el lmite inferior
y superior del rango y son evaluados slo cuando se entra en el bucle. El paso de la iteracin es siempre 1.
[<<label>>]
FOR record | row N select_clause LOOP
statements
END LOOP;
El registro o fila se asigna a todas las filas resultantes de la clusula de seleccin, y la sentencia se ejecuta
para cada una de ellas. Si el bucle se termina con una sentencia EXT, la ultima fila asignada es an
accesible despus del bucle.
EXT [ label ] [ WHEN expression ];
Si no se incluye label, se termina el lazo ms interno, y se ejecuta la sentencia que sigue a END LOOP. Si
se incluye label ha de ser la etiqueta del bucle actual u de otro de mayor nivel. EL bucle indicado se termina,
y el control se pasa a la sentencia de despus del END del bucle o bloque correspondiente.
1*.I.* E,&e)&i!ne"
PostgreSQL no dispone de un modelo de manejo de excepciones muy elaborado. Cuando el analizador, el
optimizador o el ejecutor deciden que una sentencia no puede ser procesada, la transaccin completa es
abortada y el sistema vuelve al lazo principal para procesar la siguiente consulta de la aplicacin cliente.
Es posible introducirse en el mecanismo de errores para detectar cuando sucede esto. Pero lo que no es
posible es saber qu ha causado en realidad el aborto (un error de conversin de entrada/salida, un error de
punto flotante, un error de anlisis). Y es posible que la base de datos haya quedado en un estado
inconsistente, por lo que volver a un nivel de ejecucin superior o continuar ejecutando comandos puede
corromper toda la base de datos. E incluso aunque se pudiera enviar la informacin a la aplicacin cliente, la
transaccin ya se abra
abortado, por lo que carecera de sentido el intentar reanudar la operacin.
Por todo esto, lo nico que hace PL/pgSQL cuando se produce un aborto de ejecucin durante la ejecucin
de una funcin o procedimiento disparador es enviar mensajes de depuracin al nivel DEBUG, indicando en
qu funcin y donde (numero de lnea y tipo de sentencia) ha sucedido el error.
1*.8. E7em)%!"
Se incluyen unas pocas funciones para demostrar lo fcil que es escribir funciones en PL/pgSQL. Para
ejemplos ms complejos, el programador debera consultar el test de regresin de PL/pgSQL. Un detalle
doloroso a la hora de escribir funciones en PL/pgSQL es el manejo de la comilla simple. El texto de las
funciones en CREATE FUNCTON ha de ser una cadena de texto. Las comillas simples en el interior de una
cadena literal deben de duplicarse o anteponerse de una barra invertida. An estamos trabajando en una
alternativa ms elegante. Mientras tanto, duplique las comillas sencillas como en los ejemplos siguientes.
Cualquier solucin a este problema en futuras versiones de PostgreSQL mantendrn la compatibilidad con
esto.
1*. 8.1 A%6un$" (un&i!ne" "en&i%%$" en PLJ)6SQL
Las dos funciones siguientes son idnticas a sus contrapartidas que se vern cuando estudiemos el
lenguaje C.
CREATE FUNCTON add_one (int4) RETURNS int4 AS '
BEGN
RETURN $1 + 1;
END;
' LANGUAGE 'plpgsql';
CREATE FUNCTON concat_text (text, text) RETURNS text AS '
BEGN
RETURN $1 || $2;
END;
' LANGUAGE 'plpgsql';
Funciones PL/pgSQL para tipos compuestos De nuevo, estas funciones PL/pgSQL tendrn su equivalente
en lenguaje C.
CREATE FUNCTON c_overpaid (EMP, int4) RETURNS bool AS '
DECLARE
emprec ALAS FOR $1;
sallim ALAS FOR $2;
BEGN
F emprec.salary SNULL THEN
RETURN ''f'';
END F;
RETURN emprec.salary > sallim;
END;
' LANGUAGE 'plpgsql';
1*.8.2 Pr!&e#imien!" #e"en&$#en$#!" en PLJ)6SQL
Estos procedimientos desencadenados aseguran que, cada vez que se inserte o actualice un fila en la tabla,
se incluya el nombre del usuario y la fecha y hora. Y asegura que se proporciona un nombre de empleado y
que el salario tiene un valor positivo.
CREATE TABLE emp (
empname text,
salary int4,
last_date datetime,
last_user name); CREATE FUNCTON emp_stamp () RETURNS OPAQUE AS
BEGN
-- Check that empname and salary are given
F NEW.empname SNULL THEN
RASE EXCEPTON ''empname cannot be NULL value'';
END F;
F NEW.salary SNULL THEN
RASE EXCEPTON ''% cannot have NULL salary'', NEW.empname;
END F; -- Who works for us when she must pay for?
F NEW.salary < 0 THEN
RASE EXCEPTON ''% cannot have a negative salary'', NEW.empname;
END F; -- Remember who changed the payroll when
NEW.last_date := ''now'';
NEW.last_user := getpgusername();
RETURN NEW;
END;
' LANGUAGE 'plpgsql';
CREATE TRGGER emp_stamp BEFORE NSERT OR UPDATE ON emp
FOR EACH ROW EXECUTE PROCEDURE emp_stamp();