Curso de PostgreSQL

EQ Soft Consultoría y Soporte E.I.R.L.Http://[email protected]éfonos: (51) 01–5645744 / 01-5645424 / 997244926 / 997003957

Curso de PostgreSQL DBA 1/186

Curso de PostgreSQL DBACurso de PostgreSQL DBA20102010

[email protected]@eqsoft.net

http://www.eqsoft.net/

mailto:[email protected]



●Día 1: Instalación y Configuración

●Día 2: Objetos de la DB y Accesos

●Día 3: SQL y Tipos de datos especiales

●Día 4: Transacciones, Functions, Triggers y Rules

●Día 5: Mantenimiento y análisis de querys





Instalación y Configuración

1. Instalación:

3 forma de instalación son las más comunes:

●Instalación vía paquetes instaladores (deb ó rpm)● Ventajas: mantenimiento prácticamente 0● Desventajas: ramas congeladas o sin actualizar por mucho tiempo

●Compilación desde el código fuente (descargado o por Ports/Portage)● Ventajas: Rápida ejecución, menos recursos, uso de última versión, posibilidad de añadir nuevas funcionalidades extendidas.

● Desventajas: Mantenimiento manual, no es sencillo actualizar(salvo en ports/portage)

●Paquetes no oficiales de instalación binarios● Ventajas: Instalación de una versión específica● Desventajas: Imposible de mantener






1. Instalación:

Instalación vía paquetes instaladores (deb ó rpm)● Consideraciones : mantener siempre actualiza mientras no se mueva entre ramas.

●Compilación desde el código fuente (descargado o por Ports/Portage)● Consideraciones : no instalar en sistemas que usan administradores de paquetes.

●Paquetes no oficiales de instalación binarios● Consideraciones: usar solo en casos en que se requiera una versión especifica, recomendable siempre tener una copia de la versión de producción para casos de desastres.






1.Instalación

Requerimientos de hardware:

●Procesador : si planea ejecutar Querys muy complejos es recomendable utilizar plataformas de 64bits.

●Memoria : mientras más ram se pueda tener es mejor, especialmente si se van a ejecutar Querys que van a mover mucha data, mientras mayor capacidad tenga el cache mejor será el rendimiento de las consultas.

●Disco : la cantidad de espacio dependerá del volumen de datos, recomendaciones:

●SCSI, para bases de datos relativamente medianas pero donde se requiere un alto acceso a los datos, entorno muy propenso a caídas de servidor.

●SATA, para bases de datos muy grandes pero con no muy altos requerimientos de acceso a los mismos, usar sistemas de archivos con Journaling (ext4 por ejemplo) para minimizar riesgos en entornos propensos a caídas.

●SSD, para cache de la DB, no usar para almacenamiento de datos “real” debido a su “fragilidad” en entornos propensos a caídas.

●Arreglo de discos, entornos muy grandes de datos con mucho acceso a los mismos.






1.Instalación

¿Que Linux usar? :

●Enterprise Edition●Ventajas: muy seguros, actualizaciones centradas principalmente en la seguridad.

●Desventajas: versiones antiguas incluso al momento de su lanzamiento.

CentOS, Ubuntu Server, RedHat, Suse

●Desktop Edition●Ventajas: actualizaciones constantes, se encuentran versiones más recientes.

●Desventajas: no siempre bien probadas, principalmente se enfocan en soltar la versión más reciente posible., mayor sensibilidad a problemas de seguridad.

Ubuntu, Fedora, Suse






1. Instalación

¿Unixs Libres? :

●FreeBSD es una excelente opción, gestiona muy bien múltiples conexiones y libera los procesos rápidamente, consumo de recursos increíblemente bajo, soporte comunitario más amplio de todos los BSDs (OpenBSd ó NetBSD).

●OpenSolaris evaluar con cuidado, ¿seguirá siendo libre?, poco soporte comunitarios, se sabe que ZFS es un sistema de archivos excelente para PostgreSQL, se conocen experiencias de muchos procesadores virtualizados con PostgreSQL.

●¿Solaris y AIX?, buenas plataformas, evaluar bien los costos, seguramente solo se encontrarán versiones antiguas de PostgreSQL disponibles para estas plataformas o se requerirán versiones especificas de muchas librerías dependencias.






Instalando......






1. Instalación:

●La mayoría de las distribuciones actuales generan los directorios necesarios para correr el cluster de la DB, el caso de Ubuntu:

● /etc/postgresql <-- archivos de configuración, separados por versión principalmente pg_hba.conf y postgresql.conf.

● /usr/lib/postgresql <-- binarios y librerías, separados por versiones, separados por versión.

● /var/lib/postgresql <-- data de la DB, separados por versión.

●El usuario administrador más común creado por los instaladores es “postgres”, alternativamente es “pgsql” (en otras distribuciones).






1. Instalación:

●Dentro de /var/lib/postgresql/x.y/main (reemplazar x.y con la versión de su PostgreSQL) encontrará los directorios de trabajo de la base de datos:

●Base <-- directorio de data●global <-- directorio de data global del sistema●pg_clog <-- directorio de resultado de transacciones ●pg_multixact <-- locks●pg_stat_tmp <-- archivos temporales de las estadísticas de las dbs●pg_subtrans <-- usado en control de transacciones●pg_tblspc <-- enlaces simbólicos a los tablespaces●pg_twophase <-- usado en control de transacciones●pg_xlog <-- directorio de WAL (historia de movimientos de data, es la que asegura que la dbms sea ACID)

2 archivos adicionales:●postmaster.opts <-- comando con el que se ejecuto el servicio de la dbms ●postmaster.pid <-- “pid” del proceso del sistema, en raras ocasiones la dbms se bloquea al reiniciar el servicio porque no se elimina este archivo, se puede borrar manualmente pero jamas mientras el servicio este iniciado.






2. Asegurando el sistema.

Por defecto PostgreSQL viene configurado para dar accesos en “localhost”, los usuarios comunes de administración son “postgres” y “pgsql”.

Vamos a crear un nuevo “Super Usuario” desde consola:

usuario@host: sudo su – postgres <-- ingrese su password

postgres@host: createuser admindb <-- admindb es el usuario a crear¿Será el nuevo rol un superusuario? (s/n) <-- tendrá el mismo nivel del usuario “postgres” tiene permisos especiales a los catálogos de objetos del Sistema.postgres@host: psql template1 <-- ingresamos para cambiar el Password de “admindb”template1=# alter user admindb password 'dbadmin'; <-- asignamos el nuevotemplate1=# alter user postgres password 'dbpgsql'; Password.



mailto:usuario@host

mailto:postgres@host

mailto:postgres@host




2. Asegurando el sistema

Ahora necesitamos que no cualquier persona con acceso físico al “servidor” pueda ingresar a la base de datos, para ello editamos el archivo “pg_hba.conf”.

usuario@host: sudo nano /etc/postgresql/8.4/main/pg_hba.conf <-- reemplace 8.4 por suDICE: versión instalada# Database administrative login by UNIX socketslocal all postgres ident# "local" is for Unix domain socket connections onlylocal all all ident# IPv4 local connections:host all all 127.0.0.1/32 ident# IPv6 local connections:host all all ::1/128 md5DEBE DECIR:# Database administrative login by UNIX sockets#local all postgres ident# "local" is for Unix domain socket connections onlylocal all all password <-- obligamos a que todo usuario # IPv4 local connections: conecte localmente escribahost all all 127.0.0.1/32 password su password# IPv6 local connections:#host all all ::1/128 md5 <-- usamos esto solo si tenemos protocolo Ipv6.



mailto:usuario@host




2. Asegurando el sistema

Reiniciamos el sistema

usuario@host: sudo /etc/init.d/postgresql-X.Y restart <-- X.Y la versión Instalada.

Porque hicimos esto:

a) Hemos creado un password para el usuario administrador superior “postgres”.

b) Trabajaremos con un usuario alterno para mayor seguridad.

c) Evitamos que cualquier persona con acceso al servidor entre a la base de datos si conocer los passwords.

Debilidad:pg_hba.conf, si lo pueden editar nos desasen la seguridad.



mailto:usuario@host




3. Archivo de configuración pg_hba.conf

“pg_hba.conf” nos permite definir (en orden de aplicación):

a)Conecciones locales (x socket) ó de host seguras o inseguras (x TCP/IP)b)Base datos a la que nos podemos conectarc)Usuarios que se pueden conectar a las DBsd)Direcciones autorizadas para conectarse (solo en caso TCP/IP)e)Tipo de autenticación

# Database administrative login by UNIX socketslocal all postgres ident# TYPE DATABASE USER CIDR-ADDRESS METHOD# "local" is for Unix domain socket connections onlylocal all all ident# IPv4 local connections:host all all 127.0.0.1/32 ident# IPv6 local connections:host all all ::1/128 md5







a)Conecciones locales (x socket) ó de host seguras o inseguras (x TCP/IP)

Posbles valores:

Local <-- conexiones por socket, más rápidas, solo si la aplicación que hará uso de la db esta en el mismo servidorHost <-- lo normal, conexiones vendrán por la red, puede o no tener Soporte SSLHostssl <-- solo conexión SSLHostnossl <-- solo sin SSL






Configuración básica:


b)Base datos a la que nos podemos conectar

Se pueden definir conexiones para todas las db usando “ALL” o una específica mencionándola directamente.

Recomendación: no usen combinaciones de mayúsculas y minúsculas.

Se puede usar sameuser, samegroup, samerol para indicar que la base de datos a la que me conecto es la misma que mi nombre de usuario, grupo ó rol.

c)Usuarios que se pueden conectar a las Dbs

Podemos especificar restricciones para todos los usuarios usando “ALL” o para uno específico escribiendo su nombre, si pones “+” por detras es el nombre de un grupo.

En b) y c) podemos poner varias db y usuarios separados por comas.







d)Direcciones autorizadas para conectarse (solo en caso TCP/IP)

Podemos especificar IPs directamente o por rango

192.168.1.10/32 <-- solo la IP mencionada 192.168.1.0/24 <-- todo el segmento 192.168.1.x 192.168.0.0/16 <-- todo el segmento 192.168.x.x 192.0.0.0/8 <-- todo el segmento 192.x.x.x 0.0.0.0/0 <-- todo el mundo

También podemos especificar IP y netmask (poco usado).

Se puede especificar IP de diferentes redes (no todo debe estar en 192.x.x.x).

Esto solamente se utiliza en el escenario donde el primer parametro es HOST, HOSTSSL ó HOSTNOSSL.







e)Tipo de autenticación

PostgreSQL provee diferentes tipos de autenticación, los mas comunes:

Trust <-- permite que se pueda ingresar a la DB sin passwordReject <-- cierra el acceso a una DB o a las direcciones especificadasPassword <-- requiere que se especifique el password del usuarioIdent <-- el usuario a usar debe ser del sistema operativo y debe a la vez ser usuario de la db, usada en conexiones localesLdap <-- para autentificaciones contra un servicio como OpenLdap

Md5, gss, sspi, krb5, radius, cert, pam son de menos uso y requieren configuraciones de otros servicios (como Ldap).

Cualquier cambio en este archivo requiere reiniciar el servicio del PostgreSQL.






4. Archivo de configuración postgresql.conf

El archivo “postgresql.conf” contiene los parametros de configuración del rendimiento y funcionalidad del dbms, algunos parámetros principales:

listen_addresses = 'localhost' <-- permite especificar si las conexiones a la db son locales o de red (poner “*”).Port = 5432 <-- es el puerto TCP que va a escuchar el Dbms para aceptar conexiones, es posible Tener diferentes instalaciones en el Mismo servidor pero especificando Diferetnes puertos.max_connections = 100 <-- máximo de conexiones simultaneas que aceptará el servidor.shared_buffers = 24MB <-- indica la cantidad de RAM que usa el Dbms para trabajar las consultas, no puede ser mayor a el valor guardado en /proc/sys/kernel/shmmax Modificar /etc/sysctl.conf añadiendo kernel.shmmax=[nuevo_valor_en_#entero]








log_destination = 'stderr' <-- permite generar el log de la dbms. Stderr, manda el log a donde se especifique Syslog, manda el log a /var/log/messages log_connections = off <-- permite loggear las conexiones que recibe la Dbms, ayuda mucho a depurar el pg_hba.conflog_statement = 'none' <-- permite loggear los querys que procesa la Dbms. none, no loggea querys all, loggea todos los querys, bien o mal procesados ddl, loggea los comandos que modifican Estructuras en la db mod, loggea los mismos comandos que ddl más Comandos de movimiento de data








autovacuum = on <-- activa la “limpieza” de páginas no-activas en el directorio donde se almacena la data, tomar en cuenta que este es un “lazy vacuum” no un “full vacuum” y que los valores de presición del vacuum no deben generar congestión en la base de datos.lc_messages = 'es_PE.utf8' <-- determina el tipo de “locale” para el almacenamiento de la data (internacionalización), por defecto se usa el mismo del sistema operativo, recomendación no modificarlo.

Cualquier cambio en este archivo requiere reiniciar el servicio del PostgreSQL.






Archivo de configuración pg_hba.conf y postgresql.conf

Practica






5. Instalando PhpPgAdmin y PgAdmin3

PhpPgAdmin http://phppgadmin.sourceforge.net/

Aplicación Web que nos permite administrar la base de datos, contiene toda la funcionalidad necesaria para un DBA.

Puede instalarse de “fuentes” o del repositorio de su distribución de Linux (versiones más antiguas que la última estable).

Archivo de configuración “conf/config.inc.php”.

$conf['servers'][0]['host'] = ''; <-- host ó IP de la dbms$conf['servers'][0]['port'] = 5432; <-- puerto para conexiones Tcp/Ip$conf['extra_login_security'] = true; <-- indispensable para que no Ingrese alguien a la dbms con los Usuarios clásicos.$conf['owned_only'] = true; <-- para ver solo los objetos de los Cuales eres propietario



http://phppgadmin.sourceforge.net/





PgAdmin3 http://www.pgadmin.org/

Aplicativo GUI que permite una administración y depuración de los objetos de una dbms PostgreSQL.

Instalar de preferencia desde los repositorios de su distribución de Linux.

Una de las funcionalidades más importantes es el Debugger para funciones, pero requiere que se compile desde código fuente un “contrib” adicional para la base de datos.







Practica






5. Afinando Postgresql

PostgreSQL no requiere demasiado trabajo de afinamiento, básicamente concentra toda la labor de esto en los parámetros de postgresql.conf

Los valores que tiene postgresql.conf están pensados para trabajar en una configuración de hardware mínima.

a)como calcular el valor de SHARED_BUFFERS

Shared_buffers nos dice cuanta memoria va a consumir la dbms, se recomeinda que sea al menos 10% a 25% de la ram disponible en el sistema y hasta un 40%, el valor nunca puede ser jamas al informado en “/proc/sys/kernel/shmmax”.

Para medir el valor correcto debemos contar cuantas “páginas” caben en la cantidad de ram asignada en shared_buffers, una página generalmente mide 8kb, por ejemplo si tenemos 4gb de ram asignaremos 400mb (400mb no es exacto el 10%):

En postgresql.conf ponemos:shared_buffers=400mb







a)como calcular el valor de SHARED_BUFFERS

Calculamos el valor en shmmax:

400mb x 1024kb = 409600 <-- cantidad de kb a utilizar por el buffer409600 / 8 = 51200 <-- cantidad de páginas a utilizar por el buffer51200 x 8192b = 419430400 <-- cantidad mínima de ram en bytes que se debe configurar Debe considerarse que hay otras aplicaciones que hacen Uso de esta cantidad de ram asignada.

Abrimos el archivo “/etc/sysctl.conf” y añadimos:kernel.shmmax = 421527552 <-- añadimos un par de megas más para asegurarnos que no Nos faltará ram.







b)como calcular el valor de WORK_MEM

work_mem es el espacio de memoria que se usará para los ordenamientos de los datos cuando se ejecutan consultas, no existe una formula exacta de cálculo dependerá de que tanta data se mueva en las consultas que ejecutamos y cual es la concurrencia de ejecución de las consultas.

La regla dice, si las consultas se ejecutan con poca concurrencia entonces asignar entre 2% a 4% de la ram disponible será ideal, pero si la concurrencia es alta entonces debe asignarse menos memoria debido a que cada consulta consume la misma cantidad de ram.

work_men = 163MB <-- 4% de 4gb (redondeado)







c)temp_buffers

Es la cantidad de memoria que tendrá asignada cada conexión al dbms para manejo de tablas temporales, esta no se libera hasta que la sesión muera, cada sesión podría manejar un tamaño difereten y mayor al de default (8mb) pero solo hasta antes de generar la primera tabla temporal.

d)max_locks_per_transaction

Permite indicar cuantos objetos se pueden bloquear en una transacción, un registro no se considera un objeto, el default es 64 solo valdría la pena subirlo si es que tenemos transacciones que bloquean muchos más objetos únicos (tablas) que este valor, obviamente el consumo de memoria crecerá.

e)max_connections

Determina cuantas conexiones soportará el dbms, subirlo significará un consumo de recursos adicional en el OS (sistema operativo), y en realidad no servirá de mucho si es que el OS no soporta esta carga de trabajo.








f)random_page_cost

Determina en que momento se van a utilizar índices ó búsquedas secuenciales, el valor por defecto es 4, se recomienda aumentarlo para discos lentos y bajarlo para discos rápidos.

Considere que los índices son efectivos si la variedad de datos es alta, si es baja entonces es probable que aunque se mueva la configuración se ejecuten búsquedas secuenciales.

g)effective_cache_size

Setea el tamaño de cache en RAM que se usará en una consulta, el valor por defecto es 128Mb, un valor alto facilitará el uso de índices, un valor bajo hará que se prefiera el uso de búsquedas secuenciales, se recomienda como máximo 50% del total de la RAM.








h)statement_timeout

Configura cuanto tiempo puede demorar un query en ejecutarse, evita que se lancen querys extremadamente pesados que demoren mucho tiempo en ejecutarse, por defecto es 0 (desactivado) pero se expresa en milisegundos, OjO configurarlo afectará todos los querys.





Objetos de la DB y Accesos

1. Objetos convencionales en la DB

PostgreSQL permite crear objetos comunes de uan base de datos tales como:

●Base datos●Tablas●Vistas●Schemas●Usuarios●Grupos●Roles

●Funciones (que sería un simil a store procedures)●Triggers●Rules

●Etc, etc.







a) Base datos

●Si puede hacer por consola del OS usando “createdb” o desde consola de PostgreSQL (psql) usando “create database”.

●Podemos especificar quien será el owner de la db, si no se especifica por defecto el owner es el usuario que la esta creando.

●Desde la versión 8.3 PostgreSQL se une fuertemente con el Locate del OS, si no se especifica el encoding o el locate se asumirá el del OS

●La db asume la estructura de una db “template”, esta es por defecto la db “template1”, podemos usar cualquier db como template siempre y cuando no exista ningún usuario logeado en ella, se recomienda no cambiar la estructura de template1, solo se copia estructura y no data.

CREATE DATABASE name [ [ WITH ] [ OWNER [=] user_name ] [ TEMPLATE [=] template ] [ ENCODING [=] encoding ] [ LC_COLLATE [=] lc_collate ] [ LC_CTYPE [=] lc_ctype ] [ TABLESPACE [=] tablespace ] [ CONNECTION LIMIT [=] connlimit ] ]







a) Base datos

Teóricamente no hay problemas de recibir data en Latin1 en una db UTF8, solo es necesario hacer esto:

ALTER DATABASE base_de_datos SET client_encoding TO 'latin1';

Para cambiar el encoding de toda la db:

update pg_database set encoding=8 where datname=’base_de_datos’;

Para ver la tabla de códigos completa: http://www.lscvsystems.com/blog/?p=32



http://www.lscvsystems.com/blog/?p=32





b) Tablas

Crear una tabla de un Type nos ayuda a tener estructuras pre-construidas para los datos.

prueba4=# create type tpy_usuario as (id integer, password char(25), nombre varchar(100));

prueba4=# create table tbl_usuario of tpy_usuario;

prueba4=# select * from tbl_usuario; id | password | nombre ++ (0 rows)

prueba4=# drop type tpy_usuario cascade;NOTICE: drop cascades to table tbl_usuarioDROP TYPE







b) Tablas

Un campo de la tabla puede tener la estructura de un Type.

prueba4=# create table tbl_usuario2 ( id serial, datos_unicos tpy_usuario);

prueba4=# insert into tbl_usuario2 values (1,(1,'password','nombre'));prueba4=# insert into tbl_usuario2 (datos_unicos.id, datos_unicos.password, datos_unicos.nombre) values (2, 'password2', 'nombre2');

prueba4=# select * from tbl_usuario2; id | datos_unicos + 1 | (1,"password ",nombre) 1 | (2,"password2 ",nombre2)

prueba4=# select (datos_unicos).password from tbl_usuario2; password password password2







b) Tablas

Un campo de la tabla puede tener la estructura de un Type.

Borrar el type hará que se pierdan todas los campos creados a partir de este en todas las tablas donde se haya usado.

prueba4=# drop type tpy_usuario cascade;NOTICE: drop cascades to 2 other objectsDETAIL: drop cascades to table tbl_usuariodrop cascades to table tbl_usuario2 column datos_unicosDROP TYPE

prueba4=# select * from tbl_usuario2; id 1 1







b) Tablas

INHERITS nos permite heredar a la estructura de nuestra nueva tabla la estructura de otra tabla.

prueba4=# create table tbl_padre (id integer, nombre varchar(100));prueba4=# create table tbl_hijo (direccion varchar(200)) INHERITS (tbl_padre);CREATE TABLEprueba4=# select * from tbl_hijo; id | nombre | direccion ++(0 rows)

prueba4=# drop table tbl_padre cascade;NOTICE: drop cascades to table tbl_hijoDROP TABLE

LIKE genera el mismo efecto pero al borrar la tabla padre no se pierde la estructura.

prueba4=# create table tbl_hijo2 (like tbl_padre);prueba4=# create table tbl_hijo3 (like tbl_padre, casa varchar(300));







c) Vistas

Una interesante funcionalidad extendida es la posibilidad de tener vistas “updatable”, es soportado solo insert y update.

prueba4=# create table tbl_vista ( id integer, nombre varchar(100));

prueba4=# crea view vw_vista as select * from tbl_vista;

prueba4=# create rule rul_vista as on insert to vw_vista do instead insert into tbl_vista (id,nombre) values (new.id, new.nombre);

prueba4=# insert into vw_vista (id,nombre) values (1,'ernesto');

prueba4=# select * from tbl_vista; id | nombre ----+--------- 1 | ernesto







d) Schemas

Los esquemas son contenedores de objetos dentro de una db, por default trabajamos en el schema PUBLIC.

La principal utilidad puede estar en la administración de permisos a los objetos de la db ó simplemente la organización.

prueba4=# create schema public2;prueba4=# create table public2.tbl_prueba(id integer);prueba4=# create table public.tbl_prueba(id integer); prueba4=# insert into tbl_prueba values(1);prueba4=# insert into public2.tbl_prueba(2);

prueba4=# select * from public.tbl_prueba; id ---- 1prueba4=# select * from public2.tbl_prueba; id ---- 2







e) Domain

Los domains nos dejan crear tipos de datos validados, si lo eliminamos eliminamos todos los campos de todas las tablas que lo han usado.

prueba3=# create domain dmn_adulto as integer check (value > 18 and value < 60);prueba3=# create table tbl_persona(id int, edad dmn_adulto);

prueba3=# insert into persona values (1,25);INSERT 0 1prueba3=# insert into persona values (1,5); ERROR: value for domain dmn_adulto violates check constraint "dmn_adulto_check"

prueba3=# drop domain dmn_adulto cascade;NOTICE: drop cascades to table persona column edadDROP DOMAINprueba3=# select * from persona; id ---- 1







f) Sequence

Una funcionalidad interesante puede ser aplicable en entornos donde se producen muchas “insersiones” de data, y es mantener una cantidad de números en memoria para un acceso más rápido a los contadores.

prueba4=# create sequence contador cache 100; <-- reserva 100 números en Cache

Cycle permite reiniciar el contador con el mínimo valor especificado cuando este llega a su máximo valor declarado.

prueba4=# create sequence cmin_max cycle minvalue 1 maxvalue 3;

Increment permite definir cada cuantas unidades aumentará el contador, positivo ó negativo.

prueba4=# create sequence salto increment -10;







Practica






2. Accesos

b) Los permisos

Por defecto uno tiene permisos totales sobre los objetos que haya creado con su propio rol, ningún rol puede acceder a un objeto creado por otro rol.

Se usan 2 comandos principales para asignación de permisos Grant (autoriza) y Revoke (desautoriza).

prueba4=# create role usr1 password 'prueba';prueba4=# create role usr2 password 'prueba';

Como usr1prueba4=> create table tbl_prueba ( id integer);

Como usr2prueba4=> select * from tbl_prueba;ERROR: permission denied for relation tbl_prueba






2. Accesos

b) Los permisos - GRANT

●GRANT ON TABLE●GRANT ( column ) ON TABLE●GRANT ON SEQUENCE●GRANT ON DATABASE●GRANT ON FOREIGN DATA WRAPPER <-- para conexiones Dlink●GRANT ON FOREIGN SERVER <-- para conexiones Dlink●GRANT ON FUNCTION●GRANT ON LANGUAGE●GRANT ON LARGE OBJECT●GRANT ON SCHEMA●GRANT ON TABLESPACE●GRANT role_name TO role_name






2. Accesos


●GRANT ON TABLE●GRANT ( column ) ON TABLE

prueba4=# create role usr3 password 'usr3' login;prueba4=# create table tbl_acceso (id integer, nombre varchar(100));prueba4=# grant insert on table tbl_accesos to usr3;

Como usr3

prueba4=> select * from tbl_acceso;ERROR: permission denied for relation tbl_acceso

prueba4=> insert into tbl_acceso values ( 1, 'ernesto');INSERT 0 1






2. Accesos


●GRANT ON TABLE●GRANT ( column ) ON TABLE

prueba4=# grant select (nombre) on tbl_acceso to usr3;GRANT

Como usr3

prueba4=> select * from tbl_acceso;ERROR: permission denied for relation tbl_acceso

prueba4=> select nombre from tbl_acceso; nombre --------- ernesto

No existe GRANT para “vistas”, se tratan como tablas (usar ON TABLE).






2. Accesos


●GRANT ON DATABASE●GRANT ON SCHEMA

prueba4=# create table sin_acceso.prueba(id integer);CREATE TABLE

Como usuario usr3

prueba4=> select * from sin_acceso.prueba;ERROR: permission denied for schema sin_accesoLINE 1: select * from sin_acceso.prueba;

Como superusuario:

prueba4=# grant usage on sin_acceso to usr3;prueba4=# grant select on table sin_acceso.prueba to usr3;






2. Accesos

b) Los permisos - REVOKE

Sigue más o menos la misma estructura de GRANT salvo que en vez de dar permisos los retira.

REVOKE [ GRANT OPTION FOR ] { { SELECT | INSERT | UPDATE | DELETE | TRUNCATE | REFERENCES | TRIGGER } [,...] | ALL [ PRIVILEGES ] } ON { [ TABLE ] table_name [, ...] | ALL TABLES IN SCHEMA schema_name [, ...] } FROM { [ GROUP ] role_name | PUBLIC } [, ...] [ CASCADE | RESTRICT ]






2. Accesos

c) Usuarios del dbms vs Usuarios de la aplicación

Muchas aplicaciones (especialmente web) siguen la lógica de conectarse a la dbms usando un solo usuario y controlan los accesos a opciones del sistema.

Esto es muy práctico de mantener, no llena la dbms de usuarios, PERO, permite que todos tengan el mismo nivel de acceso a todos los objetos de la db con los problemas que esto puede tener.

Para ver los accesos superiores de un rol puede utilizar este comando:

prueba4=> select * from pg_user; usename | usesysid | usecreatedb | usesuper | usecatupd | passwd | valuntil | useconfig -----------+----------+-------------+----------+-----------+----------+----------+----------- postgres | 10 | t | t | t | ******** | | dbadmin | 16392 | t | t | t | ******** | | pgsql | 16643 | t | t | t | ******** | | usr3 | 24410 | f | f | f | ******** | infinity | usr4 | 24414 | f | f | f | ******** | |






2. Accesos

c) Usuarios del dbms vs Usuarios de la aplicación

OjO, todas las claves por defecto se guardan encriptadas en MD5 (lo cual es relativamente seguro, pero no totalmente) sin embargo cerciórese de no generar claves sin encriptación ya que fácilmente se puede ver estas con el siguiente comando:

template1=# create role usr8 unencrypted password 'se_me_ve_todo' login;

template1=# select usename, passwd from pg_shadow; usename | passwd + postgres | md54abfba9c735cfbc34d97b56a593120c0 dbadmin | md5695c0e25f6fe7c4ce633c67292190b90 pgsql | usr1 | md51575823e236277b188fdd5d691aa8d08 usr3 | md5f06099b5e97add7ed510d76e24146f1e usr8 | se_me_ve_todo






2. Accesos

PRACTICA






3. TableSpaces y Tablas Particionadas

a) Tablespace

Los tablespaces nos permite generar áreas de almacenamiento de objetos de una db en directorios ó unidades de almacenamiento diferentes a la determinada por defecto.

La ventaja de esto es que podemos balancear el trabajo de nuestra DB en diversas unidades haciendo que nuestra performanse mejore notablemente.

Un tablespace puede ser:

●Otro disco duro●Un “disco” de estado solido (SSD)●Una memoria USB●Un “disco” virtual (en RAM)●Otros tipos de unidades de almacenamiento







a) Tablespace

CREATE TABLESPACE tablespacename [ OWNER username ] LOCATION 'directory'

El owner siempre es por defecto el creador, el directorio donde se creará el tablespace debe estar VACIO y tener los permisos del usuario de Linux que ejecuta el servicio del dbms.

Como root (o con sudo):root@depeche:~# mkdir /home/tablespaceroot@depeche:~# chown postgres:postgres /home/tablespace/

En consola de PgSQL:template1=# create tablespace ts_prueba location '/home/tablespace';template1=# create table tbl_prueba(id serial) tablespace ts_prueba;

Como root:root@depeche:/home/tablespace# ls -latotal 16drwx------ 3 postgres postgres 4096 2010-10-04 12:43 .drwxr-xr-x 4 root root 4096 2010-10-04 12:35 ..drwx------ 2 postgres postgres 4096 2010-10-04 12:43 1 <-- directorio de la data-rw------- 1 postgres postgres 4 2010-10-04 12:41 PG_VERSION







a) Tablespace

Podemos usar esta funcionalidad con:

●Base de datos●Tablas●Indices

Se recomienda que los Tablespaces creados en discos virtuales ó memorias USB solo almacenen objetos de la db de los cuales se puedo presncindir como tablas temporales, esto debido a que son muy volátiles y fácil de corromper o perder los datos (por ejemplo tener un tablespace en disco virtual desaparece si alguien reinicia el servidor).

Los tablespace de índices tienen una muy buena persormanse en discos SSD.

Más sobre tablespace en ram:http://wiki.postgresql.org/wiki/La_verdad_y_la_mentira_de_los_tablespaces_en_memoria



http://wiki.postgresql.org/wiki/La_verdad_y_la_mentira_de_los_tablespaces_en_memoria





b) Tablas particionadas

Las tablas particionadas nos permiten crear diferentes espacios de almacenamiento para una data en común.

template1=# create table tbl_padre(cuenta char(10));template1=# create table tbl_hija10(cuenta char(10)) inherits (tbl_padre); template1=# create table tbl_hija20(cuenta char(10)) inherits (tbl_padre); template1=# insert into tbl_hija20 values('20.01'); template1=# insert into tbl_hija10 values('10.01'); template1=# select * from tbl_padre; cuenta ------------ 10.01 20.01 template1=# select * from tbl_hija10; cuenta ------------ 10.01







b) Tablas particionadastemplate1=# create table tbl_hija30(descripcion varchar(100)) inherits (tbl_padre); template1=# insert into tbl_hija30 values('30.01', 'orden'); template1=# select * from tbl_hija30; cuenta | descripcion ------------+------------- 30.01 | orden

template1=# select * from tbl_padre; cuenta ------------.. 30.01

template1=# create table tbl_hija40() inherits (tbl_padre);template1=# insert into tbl_hija40 values('40.01');template1=# select * from tbl_padre; cuenta ------------... 40.01

template1=# select * from tbl_hija40; cuenta ------------ 40.01








template1=# create table tbl_hija50( check (substr(cuenta,1,1) = '5' )) inherits (tbl_padre);template1=# insert into tbl_hija50 values('540.01');

template1=# insert into tbl_hija50 values('640.01');ERROR: el nuevo registro para la relación «tbl_hija50» viola la restricción check «tbl_hija50_cuenta_check»

template1=# select * from tbl_padrE; cuenta ------------... 540.01

template1=# drop table tbl_padre;ERROR: no se puede eliminar tabla tbl_padre porque otros objetos dependen de élDETALLE: tabla tbl_hija10 depende de tabla tbl_padretabla tbl_hija20 depende de tabla tbl_padretabla tbl_hija30 depende de tabla tbl_padretabla tbl_hija40 depende de tabla tbl_padreSUGERENCIA: Use DROP ... CASCADE para eliminar además los objetos dependientes.

template1=# drop table tbl_hija20;DROP TABLE








Supongamos que tenemos el caso de una tabla de movimientos contables, con millones de registros por mes y decidimos crear una tabla por mes, pero es tanta data que necesitamos grabarla en diferentes unidades físicas de almacenamiento, aplicamos:template1=# create table tbl_hija60( check (substr(cuenta,1,1) = '6' )) inherits (tbl_padre) tablespace ts_prueba;CREATE TABLE

A cada tabla “hija” podemos aplicarle sus propios índices y relaciones, al igual que a la tabla padre.template1=# create index idx_padre on tbl_padre(cuenta);CREATE INDEXtemplate1=# create index idx_padre2 on tbl_padre(cuenta) tablespace ts_prueba;CREATE INDEX

Para retirar la herencia entre las tablas.template1=# alter table tbl_hija30 no inherit tbl_padre;template1=# select * from tbl_padre; cuenta ------------ 10.01 40.01 540.01 (3 filas)








Podemos crear rules o triggers para manejar la correcta desviación de los datos cuando se intenta grabar en la tabla principal ó padre.

template1=# CREATE RULE rl_tbl_padre10 AStemplate1-# ON INSERT TO tbl_padre WHERE ( substr(cuenta,1,2) = '10' )template1-# DO INSTEAD INSERT INTO tbl_hija10 VALUES (NEW.cuenta);

template1=# insert into tbl_padre values ('10.02');template1=# select * from tbl_padre; cuenta ------------ 00.01 10.01 10.02 40.01 540.01 (5 filas)

template1=# select * from tbl_hija10; cuenta ------------ 10.01 10.02 (2 filas)








PRACTICA





SQL y Tipos de Datos Especiales

1. Creando estructuras de datos

Los Types son estructuras de datos definidas por el usuario, además de los ejemplos especificados en las láminas 35 a 37 también podemos:

a) Types de datos enumerados

template1=# create type mes as enum ('enero', 'febrero', 'marzo');CREATE TYPE

template1=# create table tbl_mes ( fecha mes);CREATE TABLE

template1=# insert into tbl_mes values ('enero');INSERT 0 1

template1=# insert into tbl_mes values ('abril');ERROR: la sintaxis de entrada no es válida para el enum mes: «abril»LÍNEA 1: insert into tbl_mes values ('abril');

El orden de los enumerados en caso de aplicar al campo un “order by” es el orden en el que fueron declarados los valores.






1. Creando estructuras de datos

b) Types de retorno de estructura de datos template1=# create type tpy_cuenta as( cmp_cuenta char(10));CREATE TYPE

template1=# create function fn_cuenta () returns setof tpy_cuenta as $$ select cuenta from tbl_padre $$ language sql;CREATE FUNCTION

template1=# select fn_cuenta(); fn_cuenta ---------------- ("00.01 ") ("10.01 ") ("10.02 ") ("40.01 ") ("540.01 ")(5 filas)






2. Tipos de datos

a)Tipos de datos numéricos

●smallint●integer●bigint●decimal●numeric●Real <-- tomar en cuenta la presición de punto flotante, por ejemplo 10 podría guardarse como 9.9999999E9

●double precision <-- mismo caso que real●Serial <-- genera automáticamente una “secuencia”, los seriales actualizan sus datos dependiendo cuantas veces se ejecute un “nextval()” de la secuencia, si la transacción no se completa se generará un “hueco” en el contador.

●Bigserial●Money <-- inserta el símbolo de la moneda por delante, podemos precisar el símbolo cambiando el “locale” del parámetro lc_monetary en postgresql.conf

●Booelan <-- true ó false, 1 ó 0






2. Tipos de datos

b)Tipos de datos caractér

●character varying() ó varchar(n)●character(n) ó char(n)●Text

c) tipo de datos fecha

●timestamp without time zone <-- considere que guardar fecha y tiempo juntos no ayuda a la formación de querys de búsqueda, por ejemplo:

prueba=# create table tbl_fecha ( fecha timestamp); prueba=# insert into tbl_fecha values ('2010-01-01'); prueba=# insert into tbl_fecha values ('2010-01-02 01:01:01'); prueba=# select * from tbl_fecha where fecha >= '2010-01-01' and fecha <= '2010-01-02'; fecha --------------------- 2010-01-01 00:00:00 prueba=# select * from tbl_fecha where fecha >= '2010-01-01' and fecha <= '2010-01-02 23:59:59'; fecha --------------------- 2010-01-01 00:00:00 2010-01-02 01:01:01●timestamp with time zone●date●time without time zone●time with time zone●interval






2. Tipos de datos

d)Tipos direcciones de red

●Cidr <-- solo Ips v.4 ó v.6●inet <-- Ips v.4 ó v.6 ó hostnames●Macaddr <-- dirección de identificador único de una NIC

prueba=# create table tbl_inet ( host cidr, hostname varchar(32));

prueba=# insert into tbl_inet values ( '192.168.1.1','192.168.1.1');INSERT 0 1

prueba=# insert into tbl_inet values ( '292.168.1.1','192.168.1.1');ERROR: la sintaxis de entrada no es válida para tipo cidr: «292.168.1.1»LÍNEA 1: insert into tbl_inet values ( '292.168.1.1','192.168.1.1'); ^

prueba=# insert into tbl_inet values ( '192.168.1.1','292.168.1.1');INSERT 0 1






2. Tipos de datos

PRACTICA






3. Tipos de datos especiales

a)Tsvector

El tipo de datos Vector nos permite almacenar cadenas en lexemas para facilitar las búsquedas de cadenas específicas en textos muy largos.

prueba=# create table tbl_vector ( campo1 text, campo2 tsvector);

prueba=# insert into tbl_vector values ( 'esta es una pruena de un vector repitiendo la palabra vector','esta es una prueba de un vector repitiendo la palabra vector');

prueba=# insert into tbl_vector values ( 'esta es una pruena de un vector repitiendo la palabra vector','esta es una prueba de un vector repitiendo la palabra vector');

prueba=# insert into tbl_vector values ( 'árbol y vector añade acentos y eñes','árbol y vector añade acentos y eñes');

prueba=# insert into tbl_vector values ( 'las ratas y los ratones estan ratoneando un rato', 'las ratas y los ratones estan ratoneando un rato');

^prueba=# select * from tbl_vector; campo1 | campo2 --------------------------------------------------------------+--------------------------------------------------------------------------- esta es una pruena de un vector | 'de' 'es' 'esta' 'prueba' 'un' 'una' 'vector' esta es una pruena de un vector repitiendo la palabra vector | 'de' 'es' 'esta' 'la' 'palabra' 'prueba' 'repitiendo' 'un' 'una' 'vector' árbol y vector añade acentos y eñes | 'acentos' 'añade' 'eñes' 'vector' 'y' 'árbol' las ratas y los ratones estan ratoneando un rato | 'estan' 'las' 'los' 'ratas' 'rato' 'ratoneando' 'ratones' 'un' 'y'







a)Tsvector

prueba=# select campo1 from tbl_vector where to_tsvector(campo1) @@ to_tsquery('añade'); campo1 ------------------------------------- árbol y vector añade acentos y eñes

prueba=# select campo1 from tbl_vector where to_tsvector(campo1) @@ to_tsquery('vector & palabra'); campo1 -------------------------------------------------------------- esta es una pruena de un vector repitiendo la palabra vector

Podemos acceder directamente al campo del vector.

prueba=# select campo1 from tbl_vector where campo2 @@ to_tsquery('pg_catalog.spanish','vector'); campo1 -------------------------------------------------------------- esta es una pruena de un vector esta es una pruena de un vector repitiendo la palabra vector árbol y vector añade acentos y eñes

Pero esto no funciona, ¿porque?

prueba=# select campo1 from tbl_vector where campo2 @@ to_tsquery('pg_catalog.spanish','palabra'); campo1 --------(0 filas)







a)Tsvector

Para una mejor administración de los datos debemos especificar el idioma en el cual estamos añadiendo los datos.

prueba=# insert into tbl_vector values('esto añade soporte en español', to_tsvector('pg_catalog.spanish','esto añade soporte en español'));prueba=# select campo2 from tbl_vector; campo2 --------------------------------------------------------------------------- 'acentos' 'añade' 'eñes' 'vector' 'y' 'árbol' 'añad':2 'español':5 'soport':3

prueba=# select campo1 from tbl_vector where campo2 @@ to_tsquery('pg_catalog.spanish','añad'); campo1 ------------------------------- esto añade soporte en español

prueba=# select campo1 from tbl_vector where campo2 @@ to_tsquery('pg_catalog.spanish','añada'); campo1 ------------------------------- esto añade soporte en español







a)Tsvector

Tenemos a nuestra disposición diferentes operadores lógicos

prueba=# delete from tbl_vector;prueba=# insert into tbl_vector values('esto añade soporte en español', to_tsvector('pg_catalog.spanish','esto añade soporte en español'));prueba=# insert into tbl_vector values('vamos a repetir vector 2 veces más, vector, vector', to_tsvector('pg_catalog.spanish','vamos a repetir vector 2 veces más, vector, vector'));

prueba=# select campo1 from tbl_vector where campo2 @@ to_tsquery('añada & vector'); campo1 --------(0 filas)

prueba=# select campo1 from tbl_vector where campo2 @@ to_tsquery('añada | vector'); campo1 ---------------------------------------------------- esto añade soporte en español vamos a repetir vector 2 veces más, vector, vector(2 filas)

prueba=# select campo1 from tbl_vector where campo2 @@ to_tsquery('!vec'); campo1 ------------------------------- esto añade soporte en español

prueba=# select campo1 from tbl_vector where campo2 @@ to_tsquery('!vec & añada'); campo1 ------------------------------- esto añade soporte en español







a)Tsvector

Para combinar operadores lógicos entre varios campos:&& <-- and●|| <-- or●!! <-- not

Los vectores se pueden indexar, para ellos existe el tipo de índice GIN.prueba=# create index idx_vector3 on tbl_vector using gin(campo2);CREATE INDEX

En caso de que los textos se actualicen demasiado seguido entonces podemos crear un trigger para que actualice la columna donde están guardados los lexemas.

Para listar los lexemas más usados:prueba=# SELECT * FROM ts_stat('SELECT campo2 FROM tbl_vector') ORDER BY nentry DESC, ndoc DESC, word LIMIT 5; word | ndoc | nentry ---------+------+-------- cociner | 1 | 5 adrià | 1 | 3 gaston | 1 | 3 mund | 1 | 3 peruan | 1 | 3







b)Arreglos

Los arreglos en PostgreSQL son como en cualquier lenguaje de programación, su longitud y dimensión es variable.

prueba4=# create table tbl_array (data int[]);prueba4=# insert into tbl_array values('{1,2,3,4,5}');prueba4=# select * from tbl_array; data ------------- {1,2,3,4,5}

prueba4=# alter table tbl_array add column data2 int[][]; prueba4=# insert into tbl_array (data2) values('{{1,2},{2,3},{3,4},{4,5},{5,6}}'); prueba4=# select * from tbl_array; data | data2 -------------+--------------------------------- {1,2,3,4,5} | | {{1,2},{2,3},{3,4},{4,5},{5,6}}







b)Arreglos

prueba4=# select data from tbl_array where data[2]=2; data ------------- {1,2,3,4,5}(1 row)

prueba4=# select data from tbl_array where data[2]=1; data ------(0 rows)

prueba4=# select data2 from tbl_array where data2[1][2]=2; data2 --------------------------------- {{1,2},{2,3},{3,4},{4,5},{5,6}}(1 row)

prueba4=# select data2 from tbl_array where data2[1][3]=2; data2 -------(0 rows)







b)Arreglos

prueba4=# alter table tbl_array add column data3 int[][3];ALTER TABLE

prueba4=# insert into tbl_array (data3) values('{{1,2,3},{2,3,4}}');INSERT 0 1prueba4=# select * from tbl_array; data | data2 | data3 -------------+---------------------------------+------------------- {1,2,3,4,5} | | | {{1,2},{2,3},{3,4},{4,5},{5,6}} | | | {{1,2,3},{2,3,4}}(3 rows)

prueba4=# select data3 from tbl_array where data3[2][3]=4; data3 ------------------- {{1,2,3},{2,3,4}}(1 row

prueba4=# select data3 from tbl_array where data3[2][5]=4; data3 -------(0 rows)







c)OIDs

Los OIDs son identificadores únicos de los objetos en la base de datos, incluso cada registro tiene un OID propio que jamas se repite en ninguna otra tabla.

prueba4=# create table tbl_oid2(id integer) with oids;

prueba4=# insert into tbl_oid2 values(1);INSERT 24446 1prueba4=# insert into tbl_oid2 values(2);INSERT 24447 1prueba4=# select * from tbl_oid2; id ---- 1 2(2 rows)

prueba4=# select oid,* from tbl_oid2; oid | id -------+---- 24446 | 1 24447 | 2(2 rows)







c)OIDs

Para obtener los oids de los objetos en la base de datos

prueba4=# select oid,relname from pg_class where substr(relname,1,3) = 'tbl'; oid | relname -------+---------------------... 24440 | tbl_oid 24443 | tbl_oid2

prueba4=# SELECT attrelid,attname FROM pg_attribute where attrelid = 'tbl_oid2'::Regclass; attrelid | attname ----------+---------- 24443 | tableoid... 24443 | oid... 24443 | id

prueba4=# SELECT attrelid,attname FROM pg_attribute where attrelid = 'vw_vista'::Regclass; attrelid | attname ----------+--------- 24380 | id 24380 | nombre







c)OIDs

Podemos borrar data apuntando a su OID

prueba4=# delete from tbl_oid2 where oid = 24447;DELETE 1

prueba4=# select * from tbl_oid2; id ---- 1(1 row)

Ahora por defecto ya no se crean OIDs para data, esto debido a que en volúmenes muy grandes de datos los OIDs podrían llegar a ser insuficientes y es por ello que se prescinde de ellos por defecto.







d)Very Large Objetcs

PostgreSQL permite guardar binarios dentro de una tabla de muchos gigas de extensión, estos files no se guardan directamente dentro de la tabla creada sino en un ambiente especial y se apunta el oid del file para acceder a este.

prueba4=# create table tbl_files( name varchar(100), file oid);

prueba4=# insert into tbl_files values('primer archivo', lo_import('/home/ernesto/Descargas/Programa.pdf'));INSERT 0 1prueba4=# select * from tbl_files; name | file ----------------+------- primer archivo | 24455(1 row

prueba4=# select lo_export(tbl_files.file,'/tmp/Programa.pdf') from tbl_files where file = '24455'; lo_export ----------- 1(1 row)







d)Very Large Objetcs

Para retirar el binario añadido a la base de datos.

prueba4=# update tbl_files set file = null; <-- borramos el link pero no la data

prueba4=# insert into tbl_files values('segundo archivo', lo_import('/home/ernesto/Descargas/LAN.png'));

prueba4=# select * from tbl_files; name | file -----------------+------- primer archivo | segundo archivo | 24456

prueba4=# select lo_unlink(tbl_files.file) from tbl_files where file = 24456; lo_unlink ----------- 1

prueba4=# update tbl_files set file= lo_import('/home/ernesto/Descargas/LAN.png') where name = 'segundo archivo'; prueba4=# select * from tbl_files; name | file -----------------+------- primer archivo | segundo archivo | 24457







PRACTICA






4. Sentencias SQL

a)Insert

prueba=# create table tbl_simple ( id serial, nombre varchar(10));NOTICE: CREATE TABLE creará una secuencia implícita «tbl_simple_id_seq» para la columna serial «tbl_simple.id»CREATE TABLE prueba=# insert into tbl_simple (nombre) values ('ernesto') returning id; id ---- 1prueba=# insert into tbl_simple (nombre) values ('juan') returning id; id ---- 2 prueba=# insert into tbl_simple (nombre) values ('estosupera10caracteres') returning id; ERROR: el valor es demasiado largo para el tipo character varying(10) prueba=# insert into tbl_simple (nombre) values ('10chars') returning id; id ---- 3






4. Sentencias SQL

a)Insert

NOTICE: CREATE TABLE creará una secuencia implícita «tbl_simple2_id_seq» para la columna serial «tbl_simple2.id»CREATE TABLE

prueba=# insert into tbl_simple2 ( nombre) select nombre from tbl_simple;INSERT 0 4

prueba=# select * from tbl_simple2; id | nombre ----+--------- 1 | ernesto 2 | juan 3 | 111 4 | 10chars(4 filas)

prueba=# insert into tbl_simple2 ( nombrE) select nombre from tbl_simple returning id; id ---- 5 6 7 8(4 filas)






4. Sentencias SQL

b)Update

prueba=# select * from tbl_simple; id | nombre ----+--------- 1 | ernesto 2 | juan 3 | 111 4 | 10chars

prueba=# update tbl_simple2 set nombre = '1'||nombre;UPDATE 8

prueba=# update tbl_simple set nombre = (select tbl_simple2.nombre from tbl_simple2 where tbl_simple2.id = tbl_simple.id);UPDATE 4

prueba=# select * from tbl_simple; id | nombre ----+---------- 1 | 1ernesto 2 | 1juan 3 | 1111 4 | 110chars






4. Sentencias SQL

b)Update

prueba=# update tbl_simple2 set nombre = '2'||nombre;

prueba=# update tbl_simple set nombre = a.nombre from ( select id, nombre from tbl_simple2) as a where tbl_simple.id = a.id;UPDATE 4

prueba=# select * from tbl_simple; id | nombre ----+----------- 1 | 21ernesto 2 | 21juan 3 | 21111 4 | 2110chars

prueba=# update tbl_simple set nombre = a.nombre from ( select id, nombre from tbl_simple2) as a where tbl_simple.id = a.id returning tbl_simple.*; id | nombre ----+----------- 1 | 21ernesto 2 | 21juan 3 | 21111 4 | 2110chars






4. Sentencias SQL

b)Update

prueba=# update tbl_simple set nombre = a.nombre from ( select tbl_simple2.id, tbl_simple2.nombre from tbl_simple2 join tbl_simple on tbl_simple.id = tbl_simple2.id) as a where a.id=tbl_simple.id returning tbl_simple.*;

id | nombre ----+------------ 1 | 321ernesto 2 | 321juan 3 | 321111 4 | 32110chars(4 filas)






4. Sentencias SQL

d)Copy

Copy es una excelente alternativa cuando debemos cargar información de millares de registros en una tabla, es mucho más eficiente que hacer varios insert o un insertde un select.

Copy además nos permite generar un un archivo exportado con datos.

prueba=# copy tbl_simple2 to '/tmp/uno.txt';COPY 8

prueba=# copy tbl_simple2(nombre) to '/tmp/uno.txt';COPY 8

prueba=# copy (select * from tbl_simple2) to '/tmp/uno.txt';COPY 8

prueba=# copy (select * from tbl_simple2) to stdin;1 321ernesto2 321juan3 3211114 32110chars5 321ernesto6 321juan7 3211118 32110chars






4. Sentencias SQL

e)Select - OVERprueba=# select * from tbl_window; mes | nombre | sueldo --------+---------+-------- 201001 | ernesto | 10 201002 | ernesto | 11 201003 | ernesto | 12 201001 | juan | 13 201003 | juan | 15 201002 | juan | 14

prueba=# select nombre, mes, sueldo, sum(sueldo) as sueldo_total over (partition by nombre) from tbl_window; nombre | mes | sueldo | sueldo_total ---------+--------+--------+------------- ernesto | 201001 | 10 | 33 ernesto | 201002 | 11 | 33 ernesto | 201003 | 12 | 33 juan | 201001 | 13 | 42 juan | 201003 | 15 | 42 juan | 201002 | 14 | 42

prueba=# select nombre, mes, sueldo, sum(sueldo) over (partition by nombre) sueldo_total, sum(sueldo) over (partition by nombre) / 3 as sueldo_promedio, (sum(sueldo) over (partition by nombre) / 3 )- sueldo as desviacion_promedio from tbl_window; nombre | mes | sueldo | sueldo_total | sueldo_promedio | desviacion_promedio ---------+--------+--------+--------------+-----------------+--------------------- ernesto | 201001 | 10 | 33 | 11 | 1 ernesto | 201002 | 11 | 33 | 11 | 0 ernesto | 201003 | 12 | 33 | 11 | -1 juan | 201001 | 13 | 42 | 14 | 1 juan | 201003 | 15 | 42 | 14 | -1 juan | 201002 | 14 | 42 | 14 | 0






4. Sentencias SQL

e)Select - OVER

prueba=# select nombre, mes, sueldo, sum(sueldo) over (partition by nombre order by nombre desc, mes ) from tbl_window; nombre | mes | sueldo | sum ---------+--------+--------+----- juan | 201001 | 13 | 13 juan | 201002 | 14 | 27 juan | 201003 | 15 | 42 ernesto | 201001 | 10 | 10 ernesto | 201002 | 11 | 21 ernesto | 201003 | 12 | 33

prueba=# select nombre, mes, sueldo, rank() over (partition by nombre order by sueldo desc) from tbl_window; nombre | mes | sueldo | rank ---------+--------+--------+------ ernesto | 201003 | 12 | 1 ernesto | 201002 | 11 | 2 ernesto | 201001 | 10 | 3 juan | 201003 | 15 | 1 juan | 201002 | 14 | 2 juan | 201001 | 13 | 3

prueba=# select nombre, sueldo, mes, sum(sueldo) over ventana, avg(sueldo) over ventana from tbl_window window ventana as (partition by nombre); nombre | sueldo | mes | sum | avg ---------+--------+--------+-----+--------------------- ernesto | 10 | 201001 | 33 | 11.0000000000000000 ernesto | 11 | 201002 | 33 | 11.0000000000000000 ernesto | 12 | 201003 | 33 | 11.0000000000000000 juan | 13 | 201001 | 42 | 14.0000000000000000 juan | 15 | 201003 | 42 | 14.0000000000000000 juan | 14 | 201002 | 42 | 14.0000000000000000






4. Sentencias SQL

e)Select – FROM ONLY

prueba=# create table ciudades ( nombre varchar(100));

prueba=# create table capitales ( capital boolean) inherits (ciudades);

prueba=# insert into ciudades values ('callao');prueba=# insert into ciudades values ('piura');prueba=# insert into capitales values ('lima', true);prueba=# insert into capitales values ('buenos aires', true);

prueba=# select * from ciudades; nombre -------------- callao piura lima buenos aires(4 filas)

prueba=# select * from only ciudades; nombre -------- callao piura(2 filas)






4. Sentencias SQL

e)Select – FETCH y LIMIT

prueba=# select * from tbl_simple2 fetch first 3 rows only; id | nombre ----+------------ 1 | 321ernesto 2 | 321juan 3 | 321111(3 filas)

prueba=# select * from tbl_simple2 limit 3; id | nombre ----+------------ 1 | 321ernesto 2 | 321juan 3 | 321111(3 filas)

A simple vista parecen iguales, pero en el caso de Limit en siguientes ocasiones donde se ejecute el query el orden en el que tome los datos no necesariamente será el mismo (en el que se almacenaron en la db) a menos que se use un ORDER BY, para FETCH el orden siempre sera igual.






4. Sentencias SQL

e)Select – FOR UPDATE / FOR SHARE

FOR UDATE bloqueda el acceso a los registros que se solicitan de tal manera que el query no desbloqueara los registros hasta que haya culminado la transacción en curso.

prueba=# select * from tbl_simple2 limit 2 for update;

FOR SHARE permite que se modifiquen los datos.






4. Sentencias SQL

e)Select – SIMILAR TO

Hacemos búsquedas por expresiones regulares

prueba4=# select * from log_regla; fecha | id | nombre | estado +++ 20101008 20:26:37.200866 | 2 | Ernesto | I 20101008 20:49:24.691783 | 8 | pedro | I 20101008 21:00:08.529349 | 1 | alejandro | U 20101008 21:21:55.82194 | 5 | pepelucho | U

prueba4=# select * from log_regla where nombre similar to '%(a|c)%'; < contiene a ó c fecha | id | nombre | estado +++ 20101008 21:00:08.529349 | 1 | alejandro | U 20101008 21:21:55.82194 | 5 | pepelucho | U

prueba4=# select * from log_regla where nombre similar to '%(x|f)%'; fecha | id | nombre | estado +++






4. Sentencias SQL

e)Select – SIMILAR TO

prueba4=# select * from log_regla where nombre similar to '(d|f)%'; < inicia con d ó f fecha | id | nombre | estado +++(0 rows)

prueba4=# select * from log_regla where nombre similar to '(p|f)%'; fecha | id | nombre | estado +++ 20101008 20:49:24.691783 | 8 | pedro | I 20101008 20:49:43.711889 | 9 | pedro | I 20101008 21:21:55.82194 | 5 | pepelucho | U 20101008 21:22:06.759216 | 5 | pepelucho1 | U

prueba4=# select * from log_regla where nombre similar to '[az]{5}'; < alfabéticos de al menos fecha | id | nombre | estado 5 letras +++ 20101008 20:49:24.691783 | 8 | pedro | I 20101008 20:49:43.711889 | 9 | pedro | I






4. Sentencias SQL

PRACTICA





Transacciones, Funciones, Triggers y Rules

1. Transacciones

El modelo ACID

A <-- Atomicidad: es la propiedad que asegura que la operación se ha realizado o no, y por lo tanto ante un fallo del sistema no puede quedar a medias.C <-- Consistencia: es la propiedad que asegura que sólo se empieza aquello que se puede acabar. Por lo tanto se ejecutan aquellas operaciones que no van a romper la reglas y directrices de integridad de la base de datos.I <-- Aislamiento (ISOLATION): es la propiedad que asegura que una operación no puede afectar a otras. Esto asegura que la realización de dos transacciones sobre la misma información sean independientes y no generen ningún tipo de error.D <-- Durabilidad: es la propiedad que asegura que una vez realizada la operación, ésta persistirá y no se podrá deshacer aunque falle el sistema.

PostgreSQL cumple todas estas condiciones.






1. Transacciones

La estructura básica de una transacción es:

BEGIN --- Querys ---COMMIT ó si hay problemas ROLLBACK

prueba=# create table tbl_transaccion ( id integer);

prueba=# begin;prueba=# insert into tbl_transaccion values(1);prueba=# insert into tbl_transaccion values(2);prueba=# commit;prueba=# select * from tbl_transaccion; id ---- 1 2

prueba=# begin;prueba=# insert into tbl_transaccion values(3);prueba=# insert into tbl_transaccion values(4);prueba=# rollback;prueba=# select * from tbl_transaccion; id ---- 1 2






1. Transacciones

SAVEPOINT, nos permite determinar en que punto deseamos ir grabando la información que vamos procesando antes de ejecutar un rollback en caso de problemas.

prueba5=# select * from tbl_usuario; id | nombre ----+------------- 8 | lucho 9 | pedro 2 | juan 3 | pedro

prueba5=# begin;prueba5=# insert into tbl_usuario (nombre) values ('manuel');prueba5=# insert into tbl_usuario (nombre) values ('rosa');prueba5=# savepoint sv_uno;prueba5=# insert into tbl_usuario (nombre) values ('carmen');prueba5=# rollback to savepoint sv_uno;prueba5=# insert into tbl_usuario (nombre) values ('lucia');prueba5=# commit;

prueba5=# select * from tbl_usuario; id | nombre ----+------------- 8 | lucho 9 | pedro 2 | juan 3 | pedro 10 | manuel 11 | rosa 13 | lucia






1. Transacciones

El comando LOCK nos permite bloquear una tabla.

prueba=# begin;BEGINprueba=# lock tbl_transaccion in exclusive mode;LOCK TABLE

En otra consola intentar esto:

prueba=# update tbl_transaccion set id = id * 2; <-- no culmina se queda en espera

En la consola anterior hacer “commit” y el update culminará.

Sin embargo si hacemos un “select” a esa tabla en otra consola la información procesará sin ningún problema, los niveles de bloqueo permiten ejecutar cierto tipo de operaciones.






1. Transacciones

Tipos de LOCK:

●ACCESS SHARE●ROW SHARE●ROW EXCLUSIVE●SHARE UPDATE EXCLUSIVE●SHARE●SHARE ROW EXCLUSIVE●EXCLUSIVE●ACCESS EXCLUSIVE

http://www.postgresql.org/docs/9.0/interactive/explicit-locking.html

Hay que se cuidadoso con este comando, todas las operaciones a una DB ejecutan algún tipo de lock pre-definido y entre ellos pueden llegar a colisionar

Para ver los locks:

prueba=# select * from pg_locks;

locktype | database | relation | page | tuple | virtualxid | transactionid | classid | objid | objsubid | virtualtransaction | pid | mode | granted ------------+----------+----------+------+-------+------------+---------------+---------+-------+----------+--------------------+-------+-----------------+--------- relation | 22073 | 10969 | | | | | | | | 2/6239 | 17247 | AccessShareLock | t relation | 22073 | 22183 | | | | | | | | 1/439 | 2498 | ExclusiveLock | t virtualxid | | | | | 1/439 | | | | | 1/439 | 2498 | ExclusiveLock | t virtualxid | | | | | 2/6239 | | | | | 2/6239 | 17247 | ExclusiveLock | t



http://www.postgresql.org/docs/9.0/interactive/explicit-locking.html




1. Transacciones

Para ver los querys que están ejecutando los locks:

SELECT waiting.locktype AS waiting_locktype, waiting.relation::regclass AS waiting_table, waiting_stm.current_query AS waiting_query, waiting.mode AS waiting_mode, waiting.pid AS waiting_pid, other.locktype AS other_locktype, other.relation::regclass AS other_table, other_stm.current_query AS other_query, other.mode AS other_mode, other.pid AS other_pid, other.granted AS other_grantedFROM pg_catalog.pg_locks AS waitingJOIN pg_catalog.pg_stat_activity AS waiting_stm ON ( waiting_stm.procpid = waiting.pid )JOIN pg_catalog.pg_locks AS other ON ((waiting."database" = other."database" AND waiting.relation = other.relation) OR waiting.transactionid = other.transactionid )JOIN pg_catalog.pg_stat_activity AS other_stm ON (other_stm.procpid = other.pid)WHERE NOT waiting.granted AND waiting.pid <> other.pid

waiting_locktype | waiting_table | waiting_query | waiting_mode | waiting_pid | other_locktype | other_table | other_query | other_mode | other_pid | other_granted ------------------+-----------------+-----------------------------------------+------------------+-------------+----------------+-----------------+-----------------------+------------------+-----------+--------------- relation | tbl_transaccion | update tbl_transaccion set id = id * 4; | RowExclusiveLock | 17741 | relation | tbl_transaccion | <IDLE> in transaction | RowExclusiveLock | 2498 | t relation | tbl_transaccion | update tbl_transaccion set id = id * 4; | RowExclusiveLock | 17741 | relation | tbl_transaccion | <IDLE> in transaction | ExclusiveLock | 2498 | t






2. Funciones

Las funciones en PostgreSQL son el equivalente a los store procedures además de funcionar como funciones en si mismas.

PostgreSQL soporta una variedad muy grande de lenguajes de programación para escribir funciones (java, perl, python, php, ruby, c, etc.) sin embargo el lenguaje de programación más desarrollado es Pl/PgSql.

Desde la versión 8.3 – 8.4 PostgreSQL ya incluye como lenguaje por defecto el Pl/PgSQL cuando creamos una DB, pero si requerimos instalarlo manualmente existen 2 opciones:

Por consola del sistema operativo :

createlang plpgsql nombre_db <-- podría requerir especificar usuario y password

Por consola psql:

prueba5=# create language 'plpgsql';






2. Funciones - Estructura

prueba5=# create or replace function <-- declaración de ingreso de una funciónf_prueba (parametro integer) <-- nombre y parámetros

returns integer as <-- declaración de tipo de dato que se retornaráPrueba5-# $$ <-- delimitador de inicio/fin de códigoprueba5$# Declare <-- zona de declaración de variables internas queprueba5$# variable integer := 10; usará la funciónprueba5$# Begin <-- inicio de código prueba5$# return parametro * variable; <-- código de la función prueba5$# end; <-- fin de códigoPrueba5$# $$ prueba5-# language plpgsql; <-- lenguaje “pl” que se está usandoCREATE FUNCTION

prueba5=# select * from f_prueba(20); <-- invocando a la función f_prueba ---------- 200(1 fila)






2. Funciones - Estructura

Podemos tener “bloques” de código anidados:

create or replace function f_prueba (parametro integer) returns integer as$$Declare variable integer := 10;Begin raise notice 'el resultado es: %', parametro * variable;

-- iniciamos segundo bloque Declare variable integer := 20; Begin raise notice 'a estas alturas es: %', parametro * variable; end; -- fin del segundo bloque

return parametro;end;$$language plpgsql;

Los bloques anidados NO SON transacciones anidadas, solo se ponen con fines de agrupamiento.






2. Funciones – Declaraciones de variables / constantes

No se pueden usar variables/constantes dentro de una función sin que estas hayan sido declaradas, el tipo de una variable puede ser cualquier tipo de datos disponible en PostgreSQL más 2 tipos de estructura de las tablas de una db.

prueba5=# create table tbl_personas (edad int, nombre varchar(100), ciudad varchar(100));

create or replace function f_prueba2 (p_edad integer, p_nombre varchar) returns integer as$$Declare v_ciudad CONSTANT varchar := 'LIMA'; v_registro tbl_personas%ROWTYPE; v_nombre tbl_personas.nombre%TYPE;Begin insert into tbl_personas(edad, nombre, ciudad) values (p_edad,p_nombre, v_ciudad); select * into v_registro from tbl_personas where nombre = p_nombre; select nombre into v_nombre from tbl_personas where nombre = p_nombre;

raise notice 'El registro guardo: % % %', v_registro.edad, v_registro.nombre, v_registro.ciudad; raise notice 'Solo el campo nombre: %', v_nombre;

return 1;end;$$language plpgsql;

prueba5=# select f_prueba2(15,'juan');NOTICE: El registro guardo: 15 juan LIMANOTICE: Solo el campo nombre: juan f_prueba2 ----------- 1






2. Funciones – Declaraciones de variables / constantes

prueba5=# create type tpy_persona as ( altura numeric, peso numeric);

create or replace function f_prueba3 (p_talla numeric, p_peso numeric) returns integer as$$Declare v_talla_peso tpy_persona; v_registro record;Begin v_talla_peso.altura := p_talla; v_talla_peso.peso := p_peso;

select * into v_registro from tbl_personas where nombre = 'juan';

raise notice 'La talla es: %' , v_talla_peso.altura ; raise notice 'El peso es: %' , v_talla_peso.peso ; raise notice 'El registro guardado:% % %', v_registro.edad, v_registro.nombre, v_registro.ciudad; return 1;end;$$ language plpgsql;

prueba5=# select f_prueba3(1.84,103);NOTICE: La talla es: 1.84NOTICE: El peso es: 103NOTICE: El registro guardo: 15 juan LIMA f_prueba3 ----------- 1






2. Funciones – Parametros

En Pl/PgSql podemos declarar parametros de entrada (IN) y de salida (OUT), ó parámetros INOUT.

create or replace function f_prueba4 ( p_quienes varchar, OUT p_nombre varchar, OUT p_apellido varchar) returns record as$$Begin p_nombre := substr(p_quienes,1,8); p_apellido := substr(p_quienes,10,8);end;$$ language plpgsql;

create or replace function f_prueba5 ( p_quienes varchar) returns integer as$$Declare nombre varchar; apellido varchar; datos record;Begin select * into nombre, apellido from f_prueba4(p_quienes) ; raise notice 'El nombre es:%', nombre; raise notice 'El apellido es:%', apellido; return 1;end;$$ language plpgsql;

prueba5=# select f_prueba5('ernesto quiñones');NOTICE: El nombre es:ernesto NOTICE: El apellido es:quiñones f_prueba5 ----------- 1







create or replace function f_prueba6 (id integer, OUT r1 refcursor, OUT r2 refcursor) returns record as$$begin open r1 for select * from tbl_personas; open r2 for select * from tbl_padre; return;end;$$ language plpgsql;

create or replace function f_prueba7 () returns integer as$$declare r1T refcursor; r2T refcursor; edad integer; nombre varchar; ciudad varchar; cuenta varchar;begin -- jalamos la data select * into r1T, r2T from f_prueba6(1); --abrimos primera tabla LOOP fetch r1T into edad,nombre, ciudad; IF NOT FOUND THEN exit; END IF; raise notice 'Tabla 1, data: % % %',edad, nombre,ciudad; end loop; close r1T; --abrimos segunda tabla select * into r1T, r2T from f_prueba6(1); LOOP fetch r2T into cuenta; IF NOT FOUND THEN exit; END IF; raise notice 'Tabla 2, data: %',cuenta; end loop; close r2T; return 1;End; $$ language plpgsql;







prueba5=# select * from f_prueba7();NOTICE: Tabla 1, data: 15 juan LIMANOTICE: Tabla 2, data: 00.01 NOTICE: Tabla 2, data: 10.01 NOTICE: Tabla 2, data: 10.02 NOTICE: Tabla 2, data: 40.01 NOTICE: Tabla 2, data: 540.01 f_prueba7 ----------- 1(1 fila)

Si la función se vuelve a declarar con el mismo nombre pero diferentes parametros o valor de retorno entonces PostgreSQL dará por entendido que son diferentes y se mantendrán todas en la dbms.

Create function prueba1() returns integer as ....

Create function prueba1(parametro varchar) returns integer as ....

Create function prueba1() returns date as ....

Create function prueba1(parametro timestamp) returns date as ....







Podemos crear funciones con N número de parametros (pero siempre del mismo tipo), se soporta anyelement, anyarray, anynonarray ó anyenum.

create or replace function f_prueba23( parametros anyarray) returns integer as$$BEGIN raise notice 'Elementos :%', parametros; raise notice 'Elemento 1:%', parametros[1]; raise notice 'Elemento 2:%', parametros[2]; return 1;END;$$ language plpgsql;

prueba4=# select * from f_prueba23(ARRAY[1,3,5,6,7]);NOTICE: Elementos :{1,3,5,6,7}NOTICE: Elemento 1:1NOTICE: Elemento 2:3

prueba4=# select * from f_prueba23(ARRAY['ernesto','juan']); NOTICE: Elementos :{ernesto,juan}NOTICE: Elemento 1:ernestoNOTICE: Elemento 2:juan

prueba4=# select * from f_prueba23(ARRAY['ernesto','juan',2]);ERROR: invalid input syntax for integer: "ernesto"LINE 1: select * from f_prueba23(ARRAY['ernesto','juan',2]);






2. Funciones – Perform

Permite ejecutar querys/funciones sin necesidad de procesar devolución de datos

create or replace function f_prueba8 (numero integer) returns integer as$$BEGIN update tbl_prueba set id = id * numero; return 1;END;$$ language plpgsql;

create or replace function f_prueba9 () returns integer as$$BEGIN perform f_prueba8(10); return 1;END;$$ language plpgsql;

prueba4=# select * from tbl_prueba; id ---- 1

prueba4=# select f_prueba9(); f_prueba9 ----------- 1

prueba4=# select * from tbl_prueba; id ---- 10






2. Funciones – STRICT

Permite la evaluación estricta de los datos que se invocan.

create or replace function f_prueba10 (p_numero integer) returns integer as$$DECLARE numero tbl_prueba.id%TYPE;BEGIN BEGIN SELECT id INTO numero FROM tbl_prueba WHERE id = p_numero; EXCEPTION WHEN NO_DATA_FOUND THEN RAISE NOTICE '>No hay datos B: % %', p_numero, numero; WHEN TOO_MANY_ROWS THEN RAISE NOTICE '>Muchos datos'; END; BEGIN SELECT id INTO STRICT numero FROM tbl_prueba WHERE id = p_numero; EXCEPTION WHEN NO_DATA_FOUND THEN RAISE NOTICE ')No hay datos B: % %', p_numero, numero; WHEN TOO_MANY_ROWS THEN RAISE NOTICE ')Muchos datos'; END; return 4; END;$$language plpgsql;






2. Funciones – STRICTprueba4=# select * from f_prueba10(1); NOTICE: )No hay datos B: 1 <NULL> f_prueba10 ------------ 4

prueba4=# select * from f_prueba10(10);NOTICE: )Muchos datos f_prueba10 ------------ 4

prueba4=# select * from f_prueba10(20); f_prueba10 ------------ 4

prueba4=# select * from tbl_prueba; id ---- 10 20 23 10 10(5 rows)






2. Funciones – Retorno de Valores y Set de datos

La declaración del tipo de dato en la sección RETURNS de una función especifica de que tipo será, son soportados los tipos de datos convencionales más estos:

● TYPES < declarados por el usuario● RECORD < estructura no definida de datos● SETOF RECORD < conjunto de estructuras de datos● (TABLA) < podemos especificar el nombre de una tabla● REFCURSOR < como SETOF RECORD

prueba4=# create type tpy_prueba as( id integer, nombre varchar(100));

create or replace function f_prueba11 (p_numero integer, p_nombre varchar) returns tpy_prueba as$$DECLARE data tpy_prueba;BEGIN data.id := p_numero; data.nombre := p_nombre; return data;END;$$language plpgsql;

prueba4=# select * from f_prueba11(10,'ernesto'); id | nombre + 10 | ernesto







create or replace function f_prueba12(p_id integer) returns record as$$DECLARE datos record;BEGIN select * into datos from tbl_prueba where id = p_id; return datos;END;$$language plpgsql;

prueba4=# select * from f_prueba12(20) as (id integer, nombre varchar); id | nombre ----+--------- 20 | Dato 20

En este caso que varios registros cumplan la condición retornará solo uno de ellos, sin preferencia alguna.







create or replace function f_prueba16(datos refcursor) returns setof refcursor as$$DECLARE datos refcursor;BEGIN open datos for select * from tbl_prueba; return next datos;END;$$ language plpgsql;

prueba4=# begin; select * into resultado from f_prueba16('data'); fetch all from data; BEGINSELECT 1 id | nombre + 10 | Dato 10 20 | Dato 20 23 | Dato 23 10 | Dato 10 10 | Dato 10(5 rows)

prueba4=# commit;COMMIT







prueba4=#create type tpy_data (id integer, nombre varchar(100));

create or replace function f_prueba13_3() returns setof tpy_data as$$BEGIN return query select id,nombre from tbl_prueba; return;END;$$language plpgsql;

prueba4=# select * from f_prueba13_3(); id | nombre + 10 | Dato 10 20 | Dato 20 23 | Dato 23 10 | Dato 10 10 | Dato 10(5 rows)







create or replace function f_prueba13_4( out p_id integer, out p_nombre varchar) returns setof record as$$BEGIN return query select id,nombre from tbl_prueba; return;END;$$language plpgsql;

prueba4=# select * from f_prueba13_4(); p_id | p_nombre + 10 | Dato 10 20 | Dato 20 23 | Dato 23 10 | Dato 10 10 | Dato 10(5 rows)






2. Funciones – Los RETURNs

Return query ó return query execute nos permiten devolver set de datos de la ejecución directa de un query, en el segundo caso puede ser un query dinámico.

create or replace function f_prueba20() returns setof tpy_data2 as$$BEGIN return query select a.id,a.fecha,b.id,b.monto from factura_cab a, factura_det b where a.id = b.fac_id; return;END;$$language plpgsql;

create or replace function f_prueba20_2() returns setof tpy_data2 as$$BEGIN return query execute 'select a.id,a.fecha,b.id,b.monto from factura_cab a, factura_det b where a.id = b.fac_id'; return;END;$$language plpgsql;






2. Funciones – Los RETURNs

Return Next lo usamos en entornos donde necesitamos preprocesar la data ejecutando código más complejo.

create or replace function f_prueba22() returns setof tpy_data3 as$$DECLARE data tpy_data3;BEGIN FOR data IN select a.id,a.fecha,b.id,b.monto, '' from factura_cab a, factura_det b where a.id = b.fac_id LOOP if data.monto > 200 then data.mensaje = 'Muy caro'; end if; RETURN NEXT data; END LOOP; return;END;$$ language plpgsql;

prueba4=# select * from f_prueba22(); id | fecha | id_det | monto | mensaje ++++ 1 | 20100101 | 1 | 100.20 | 1 | 20100101 | 2 | 100.30 | 2 | 20100102 | 3 | 200.30 | Muy caro 3 | 20100103 | 4 | 2500.30 | Muy caro






2. Funciones

PRACTICA






2. Funciones – Estructuras de Control

a) IF y CASE

create or replace function f_if_case(p_valor int) returns void as$$BEGIN IF p_valor = 1 THEN raise notice 'IF Valor UNO'; ELSEIF p_valor = 2 THEN raise notice 'IF Valor DOS'; ELSE raise notice 'IF Valor %:', p_valor; END IF;

CASE p_valor WHEN 1 THEN raise notice 'CASE Valor UNO'; WHEN 2,3 THEN raise notice 'CASE Valor DOS o TRES'; WHEN 2,3,4 THEN raise notice 'CASE Valor DOS, TRES o CUATRO'; ELSE raise notice 'CASE Valor %:', p_valor; END CASE;

CASE WHEN p_valor >= 1 and p_valor <= 6 THEN raise notice 'CASE2 Valor entre UNO y SEIS'; WHEN p_valor >=1 and (p_valor % 2) = 0 THEN raise notice 'CASE2 Valor mayor a UNO y PAR'; ELSE raise notice 'CASE2 Valor %:', p_valor; END CASE;

END;$$ language plpgsql;







b) LOOP, EXIT y CONTINUE

create or replace function f_loop(p_valor int) returns void as$$DECLARE contador integer := 0;BEGIN LOOP contador := contador + 1; RAISE NOTICE 'Valor %:', contador;

EXIT WHEN contador >= 3;

IF contador >= p_valor THEN RAISE NOTICE 'Salió por el IF';

EXIT; END IF; END LOOP;END;$$language plpgsql;

prueba4=# select f_loop(2); prueba4=# select f_loop(5);NOTICE: Valor 1: NOTICE: Valor 1:NOTICE: Valor 2: NOTICE: Valor 2:NOTICE: Salió por el IF NOTICE: Valor 3:







b) LOOP, EXIT y CONTINUE

create or replace function f_loop(p_valor int) returns void as$$DECLARE contador integer := 0;BEGIN LOOP contador := contador + 1; RAISE NOTICE 'CONTADOR :%', contador;

CONTINUE WHEN contador < 5; fuerza el loop RAISE NOTICE 'Entro al continue :%', contador;

IF contador >= p_valor THEN RAISE NOTICE 'Salió por el IF'; EXIT;END IF;

END LOOP;END;$$language plpgsql;

prueba4=# select f_loop(3); NOTICE: CONTADOR :1NOTICE: CONTADOR :2NOTICE: CONTADOR :3NOTICE: CONTADOR :4NOTICE: CONTADOR :5NOTICE: Entro al continue :5NOTICE: Salió por el IF

prueba4=# select f_loop(8);NOTICE: CONTADOR :1NOTICE: CONTADOR :2NOTICE: CONTADOR :3NOTICE: CONTADOR :4NOTICE: CONTADOR :5NOTICE: Entro al continue :5NOTICE: CONTADOR :6NOTICE: Entro al continue :6NOTICE: CONTADOR :7NOTICE: Entro al continue :7NOTICE: CONTADOR :8NOTICE: Entro al continue :8NOTICE: Salió por el IF







c) WHILE

create or replace function f_while(p_valor int) returns void as$$DECLARE contador integer := 0;BEGIN WHILE contador <= p_valor LOOP contador := contador + 1; IF contador < 5 THEN

CONTINUE; END IF; RAISE NOTICE ' Contador : %', contador; END LOOP;END;$$ language plpgsql;

prueba4=# select f_while(6); prueba4=# select f_while(2);NOTICE: Contador : 5 f_while NOTICE: Contador : 6 NOTICE: Contador : 7 (1 row)







d) FOR

create or replace function f_for(p_valor int) returns void as$$DECLARE contador integer := 0;BEGIN FOR contador IN 1..p_valor LOOP RAISE NOTICE 'Contador A %', contador; END LOOP;

FOR contador IN REVERSE p_valor..1 LOOP RAISE NOTICE 'Contador B %', contador; END LOOP;

FOR contador IN REVERSE p_valor..1 BY 2 LOOP RAISE NOTICE 'Contador C %', contador; END LOOP;

FOR contador IN 1..p_valor LOOP contador := contador + 2; RAISE NOTICE 'Contador D %', contador; END LOOP;

END;$$language plpgsql;

prueba4=# select f_for(3); NOTICE: Contador A 1NOTICE: Contador A 2NOTICE: Contador A 3NOTICE: Contador B 3NOTICE: Contador B 2NOTICE: Contador B 1NOTICE: Contador C 3NOTICE: Contador C 1NOTICE: Contador D 3NOTICE: Contador D 4NOTICE: Contador D 5 f_for (1 row)






2. Funciones – Loop de set de datos

create or replace function f_prueba22() returns setof tpy_data3 as$$DECLARE data tpy_data3; BEGIN FOR data IN select a.id,a.fecha,b.id,b.monto, '' from factura_cab a, factura_det b where a.id = b.fac_id LOOP if data.monto > 200 then data.mensaje = 'Muy caro'; end if; RETURN NEXT data; END LOOP; return;END;$$ language plpgsql;

Se puede hacer un query dinámico con:

FOR data IN EXCUTE 'select a.id,a.fecha,b.id,b.monto, '' from factura_cab a, factura_det b where a.id = b.fac_id' LOOP






2. Funciones – Mensajes

create or replace function f_raise(p_valor integer) returns void as$$

DECLARE valor varchar;

BEGIN raise notice 'Mensaje Simple';

raise notice 'El parametro es :%', p_valor;

raise notice 'Este mensaje es' using HINT = '__una sugerencia__'; raise sqlstate '23505' using MESSAGE = 'Cuando se de el ERROR 23505 saldra este mensaje'; END;$$language plpgsql;






2. Funciones – Control de errores

PostgreSQL tiene una relación de errores controlados bastante amplia.http://www.postgresql.org/docs/9.0/interactive/errcodesappendix.html

prueba5=# create table tbl_tabla2 ( id integer);prueba5=# create index idx_1 on tbl_tabla2(id) unique;

create or replace function f_error() returns void as$$BEGIN BEGIN insert into tbl_tabla2 values(1); insert into tbl_tabla2 values(1); exception when unique_violation then

raise notice 'Violo UNIQUE index'; END; BEGIN insert into tbl_tabla2 values(1); insert into tbl_tabla2 values(1); exception when sqlstate '23505' then

raise notice 'Violo UNIQUE index (2)'; END;END;$$ language plpgsql;

prueba5=# select f_error(1);NOTICE: Violo UNIQUE indexNOTICE: Violo UNIQUE index (2)



http://www.postgresql.org/docs/9.0/interactive/errcodes-appendix.html




2. Funciones – Cursores

create or replace function f_cursor1() returns void as$$DECLARE c_tabla1 refcursor; data record;BEGIN open c_tabla1 for execute 'select * from tbl_usuario'; LOOP fetch c_tabla1 into data; IF NOT FOUND THEN exit; END IF; raise notice 'Nombre: %', data.nombre; END LOOP;END;$$language plpgsql;

prueba5=# select f_cursor1();NOTICE: Nombre: ernestoNOTICE: Nombre: juanNOTICE: Nombre: pedro







create or replace function f_cursor2() returns void as $$DECLARE c_tabla1 refcursor; data record; contador integer := 0;BEGIN OPEN c_tabla1 SCROLL FOR EXECUTE 'select * from tbl_usuario'; LOOP contador = contador +1; IF contador % 3 = 0 THEN FETCH PRIOR FROM c_tabla1 INTO data; ELSE FETCH NEXT FROM c_tabla1 INTO data; END IF; IF NOT FOUND THEN exit; END IF; raise notice 'Nombre: % %', contador, data.nombre; END LOOP;END;$$ language plpgsql;

prueba5=# select f_cursor2();NOTICE: Nombre: 1 ernestoNOTICE: Nombre: 2 juanNOTICE: Nombre: 3 ernestoNOTICE: Nombre: 4 juanNOTICE: Nombre: 5 pedroNOTICE: Nombre: 6 juanNOTICE: Nombre: 7 pedro

Para mas variaciones de FETCH (siempre abrir el cursor con SCROLL para esto) http://developer.postgresql.org/pgdocs/postgres/sqlfetch.html



http://developer.postgresql.org/pgdocs/postgres/sql-fetch.html





create or replace function f_cursor4() returns void as$$DECLARE c_tabla1 refcursor; data record;BEGIN OPEN c_tabla1 FOR EXECUTE 'select * from tbl_usuario'; LOOP FETCH c_tabla1 INTO data; IF NOT FOUND THEN exit; END IF; raise notice 'Nombre: %', data.nombre; move relative 1 FROM c_tabla1; END LOOP;END;$$language plpgsql;

La característica principal de MOVE es que no devuelve data de la tabla a la cual esta unida el cursos, solo mueve el puntero de posición.

Variaciones: NEXT, PRIOR, FIRST, LAST, ABSOLUTE XX, RELATIVE XX, ALL, FORWARD XX ó ALL, BACKWARD XX ó ALL, donde XX es la cantidad de espacios







create or replace function f_cursor5( p_valor integer) returns void as $$DECLARE c_tabla1 cursor FOR select * from tbl_usuario where id = p_valor; data record; contador integer;BEGIN OPEN c_tabla1; LOOP FETCH c_tabla1 INTO data; IF NOT FOUND THEN exit; END IF; raise notice 'Nombre: %', data.nombre;

update tbl_usuario set nombre='' || data.nombre where id = data.id; GET DIAGNOSTICS contador = ROW_COUNT; también existe RESULT_OID y OID if contador = 1 then

raise notice 'Se proceso % registro', contador; end if; END LOOP;END; $$ language plpgsql;

prueba5=# select * from f_cursor5(1);NOTICE: Nombre: ernestoNOTICE: Se proceso 1 registro f_cursor5 (1 fila)

prueba5=# select * from f_cursor5(5); f_cursor5 (1 fila)






2. Funciones – Transacciones controladas por el cliente

Una transacción puede englobar a varias funciones que realizan sus transacciones por dentro, si la transacción principal no se culmina con un commit todas las transacciones anidadas dentro de ella se hacen rollback al detectarse un problema.

prueba5=# select * from tbl_usuario; id | nombre + 2 | juan 3 | pedro 1 | ernesto

create or replace function f_commit1() returns void as$$BEGIN insert into tbl_usuario (nombre) values ('lucho'); insert into tbl_usuario (nombre) values ('pedro');END;$$ language plpgsql;

create or replace function f_commit2() returns void as$$BEGIN update tbl_usuario set nombre = 'juan' where nombre = 'juan'; update tbl_usuario set nombre = 'pedro' where nombre = 'pedro';END;$$ language plpgsql;







<?php

$conn = pg_connect("host=127.0.0.1 port=5432 dbname=prueba5 user=dbadmin password=dbadmin");if ($conn <> false ) { echo "entro en la db\r\n";

pg_exec("begin");

pg_exec("select f_commit1()"); pg_exec("select f_commit2()");

pg_exec("rollback");}

?>

Nótese que la transacción principal no se esta cerrando en el código, más bien se está forzando a realizar un rollback.






2. Funciones

PRACTICA






3. TRIGGERSprueba5=# create table alumnos(id serial, nombre varchar(100), edad integer, observ varchar(100));

create or replace function ft_prueba1() returns trigger as $t_alumnos$begin IF NEW.edad is NULL THEN NEW.observ := 'NO especifica'; ELSEIF NEW.edad < 18 THEN NEW.observ := 'menor edad'; ELSEIF NEW.edad >= 18 THEN NEW.observ := 'mayor edad'; END IF; RETURN NEW;end;$t_alumnos$ language plpgsql;

prueba5=# create trigger t_alumnos BEFORE INSERT ON alumnos FOR EACH ROW EXECUTE Procedure ft_prueba1();

prueba5=# insert into alumnos (nombre,edad) values ('ernesto', null);INSERT 0 1prueba5=# insert into alumnos (nombre,edad) values ('juan', 15);INSERT 0 1prueba5=# insert into alumnos (nombre,edad) values ('pedro', 25);INSERT 0 1prueba5=# select * from alumnos; id | nombre | edad | observ +++ 1 | ernesto | | NO especifica 2 | juan | 15 | menor edad 3 | pedro | 25 | mayor edad






3. TRIGGERScreate or replace function ft_prueba2() returns trigger as $t_alumnos2$begin IF NEW.edad is NULL THEN NEW.observ := 'NO especifica'; ELSEIF NEW.edad < 18 THEN NEW.observ := 'menor edad'; ELSEIF NEW.edad > 18 and NEW.edad < 100 THEN NEW.observ := 'mayor edad'; ELSEIF NEW.edad > 100 THEN raise notice 'Ya debería estar muerto'; RETURN NULL; END IF; RETURN NEW;end;$t_alumnos2$ language plpgsql;

Prueba5=# create trigger t_alumnos2 BEFORE INSERT ON alumnos FOR EACH ROW EXECUTE Procedure ft_prueba2();

prueba5=# insert into alumnos (nombre,edad) values ('cesar', 115);NOTICE: Ya debería estar muertoINSERT 0 0prueba5=# select * from alumnos; id | nombre | edad | observ +++ 1 | ernesto | | NO especifica 2 | juan | 15 | menor edad 3 | pedro | 25 | mayor edad(3 filas)






3. TRIGGERScreate or replace function ft_prueba3() returns trigger as $t_alumnos3$begin IF NEW.edad is NULL THEN raise notice 'NO ES VALIDO, NO ACTUALIZO'; RETURN OLD; ELSEIF NEW.edad < 18 THEN NEW.observ := 'menor edad'; ELSEIF NEW.edad >= 18 and NEW.edad < 100 THEN NEW.observ := 'mayor edad'; ELSEIF NEW.edad > 100 THEN raise notice 'NO ES VALIDO, NO ACTUALIZO'; RETURN OLD; END IF; RETURN NEW;end;$t_alumnos3$ language plpgsql;

prueba5=# create trigger t_alumnos3 BEFORE UPDATE ON alumnos FOR EACH ROW EXECUTE Procedure ft_prueba3();

prueba5=# update alumnos set edad = 18 where id = 1;UPDATE 1prueba5=# update alumnos set edad = 118 where id = 2;NOTICE: NO ES VALIDO, NO ACTUALIZOUPDATE 1prueba5=# select * from alumnos; id | nombre | edad | observ +++ 3 | pedro | 25 | mayor edad 1 | ernesto | 18 | mayor edad 2 | juan | 15 | menor edad






3. TRIGGERScreate or replace function ft_prueba4() returns trigger as $t_alumnos4$begin IF TG_OP = 'INSERT' THEN IF NEW.edad is NULL or NEW.edad < 18 or NEW.edad > 100 THEN

raise notice 'Edad prohibidas'; RETURN NULL; ELSE NEW.observ = 'dato valido'; RETURN NEW; END IF; ELSEIF TG_OP = 'DELETE' THEN raise notice 'Prohibido borrar data de esta tabla'; RETURN NULL; ELSEIF TG_OP = 'UPDATE' THEN IF NEW.edad is NULL or NEW.edad < 18 or NEW.edad > 100 THEN

raise notice 'Edad prohibidas'; RETURN OLD; ELSE NEW.observ = 'En los esperado'; RETURN NEW; END IF; END IF;end;$t_alumnos4$ language plpgsql;

prueba5=# create trigger t_alumnos4 BEFORE INSERT OR UPDATE OR DELETE ON alumnos FOR EACH ROW EXECUTE Procedure ft_prueba4();

prueba5=# insert into alumnos (edad,nombre) values (16,'luis');NOTICE: Edad prohibidasprueba5=# insert into alumnos (edad,nombre) values (26,'luis');prueba5=# update alumnos set edad = 29 where id = 1;prueba5=# update alumnos set edad = 129 where id = 1;NOTICE: Edad prohibidasprueba5=# delete from alumnos where id = 1;NOTICE: Prohibido borrar data de esta tabla

prueba5=# select * from alumnos; id | nombre | edad | observ +++ 3 | pedro | 25 | mayor edad 2 | juan | 15 | menor edad 6 | luis | 26 | dato valido 1 | ernesto | 29 | En los esperado






3. TRIGGERScreate or replace function ft_prueba5() returns trigger as $t_alumnos5$begin raise notice 'NEW: %', NEW; raise notice 'OLD: %', OLD; raise notice 'TG_NAME: %', TG_NAME; raise notice 'TG_WHEN: %', TG_WHEN; raise notice 'TG_LEVEL: %', TG_LEVEL; raise notice 'TG_OP: %', TG_OP; raise notice 'TG_RELID: %',TG_RELID; raise notice 'TG_RELNAME: %',TG_RELNAME; raise notice 'TG_TABLE_NAME: %',TG_TABLE_NAME; raise notice 'TG_TABLE_SCHEMA: %', TG_TABLE_SCHEMA; raise notice 'TG_NARGS: %',TG_NARGS; raise notice 'TG_ARGV[]: %',TG_ARGV[1];end;$t_alumnos5$ language plpgsql;

prueba5=# create trigger t_alumnos5 BEFORE UPDATE ON alumnos FOR EACH ROW EXECUTE Procedure ft_prueba5();

prueba5=# update alumnos set edad = 14 where id = 1;NOTICE: NEW: (1,ernesto,14,"En los esperado")NOTICE: OLD: (1,ernesto,29,"En los esperado")NOTICE: TG_NAME: t_alumnos5NOTICE: TG_WHEN: BEFORENOTICE: TG_LEVEL: ROWNOTICE: TG_OP: UPDATENOTICE: TG_RELID: 22264NOTICE: TG_RELNAME: alumnosNOTICE: TG_TABLE_NAME: alumnosNOTICE: TG_TABLE_SCHEMA: publicNOTICE: TG_NARGS: 0NOTICE: TG_ARGV[]: <NULL>






3. TRIGGERS

CREATE TRIGGER name { BEFORE | AFTER } { event [ OR ... ] } ON table [ FOR [ EACH ] { ROW | STATEMENT } ] [ WHEN ( condition ) ] EXECUTE PROCEDURE function_name ( arguments )

create trigger t_alumnos5 BEFORE UPDATE ON alumnos FOR EACH ROW WHEN (NEW.* IS DISTINCT FROM OLD.* ) < solo en PostgreSQL 9.0 EXECUTE PROCEDURE ft_prueba5();





3. TRIGGERS

Existen ocasiones en las que necesitamos deshabilitar triggers de las tablas:

BEGIN;-- desactivamos los triggersUPDATE pg_catalog.pg_class SET

reltriggers = 0 WHERE oid = 'nombre_tabla'::pg_catalog.regclass;

-- operaciones sobre nombre_tabla ...-- activamos los triggers sobre nombre-tablaUPDATE pg_catalog.pg_class SET

reltriggers = (SELECT pg_catalog.count(*) FROM pg_catalog.pg_trigger where pg_class.oid = tgrelid)

WHERE oid = 'nombre_tabla'::pg_catalog.regclass;COMMIT;







4. RULES

Las reglas nos permiten de una manera más limitada desarrollar alguna acción ante un evento producido en una tabla ó vista, no permiten desarrollar toda una lógica como en el caso de los triggers.

create table regla (id serial , nombre varchar(100));create table log_regla( fecha timestamp , id integer, nombre varchar(100), estado char(1));

CREATE RULE rul_i_fecha AS ON INSERT TO regla DO insert into log_regla values ( now(), NEW.id, NEW.nombre, 'I');

prueba4=# insert into regla (nombre) values ('Ernesto');

prueba4=# select * from regla; id | nombre + 1 | Ernesto

prueba4=# select * from log_regla; fecha | id | nombre | estado +++ 20101008 20:26:37.200866 | 2 | Ernesto | I

Ojo con el serial “id”, al reutilizarlo se relanza el nextval y devuelve un valor erroneo, lo correcto sería:

CREATE OR REPLACE RULE rul_i_fecha AS ON INSERT TO regla DO insert into log_regla values ( now(), currval('regla_id_seq'), NEW.nombre, 'I');






4. RULES

“Instead” nos permite que la acción solicitada ya no se lleve a cabo y se realice la acción alternativa declarada en la regla.

CREATE OR REPLACE RULE rul_i_fecha AS ON INSERT TO regla DO INSTEAD insert into log_regla values ( now(), NEW.id, NEW.nombre, 'I');

prueba4=# insert into regla (nombre) values ('Ernesto4');INSERT 0 1prueba4=# select * from regla; id | nombre + 1 | Ernesto 3 | Ernesto2 5 | Ernesto3(3 rows)

prueba4=# select * from log_regla; fecha | id | nombre | estado +++ 20101008 20:26:37.200866 | 2 | Ernesto | I 20101008 20:29:47.29924 | 4 | Ernesto2 | I 20101008 20:34:00.101965 | 6 | Ernesto3 | I 20101008 20:35:08.391818 | 7 | Ernesto4 | I






4. RULES

CREATE OR REPLACE RULE rul_u_fecha AS ON UPDATE TO regla WHERE OLD.id < 6 DO insert into log_regla values ( now(), NEW.id, NEW.nombre, 'U');

prueba4=# update regla set nombre = 'alejandro' where id = 1;prueba4=# update regla set nombre = 'alejandro' where id = 9;

prueba4=# select * from regla; id | nombre + 3 | Ernesto2 5 | Ernesto3 1 | alejandro 9 | alejandro

prueba4=# select * from log_regla; fecha | id | nombre | estado +++ 20101008 20:26:37.200866 | 2 | Ernesto | I 20101008 20:29:47.29924 | 4 | Ernesto2 | I 20101008 20:34:00.101965 | 6 | Ernesto3 | I 20101008 20:35:08.391818 | 7 | Ernesto4 | I 20101008 20:39:57.221768 | 8 | Ernesto4 | I 20101008 20:49:24.691783 | 8 | pedro | I 20101008 20:49:43.711889 | 9 | pedro | I 20101008 20:59:19.761879 | 1 | Ernesto | U 20101008 21:00:08.529349 | 1 | alejandro | U






PRACTICA





Mantenimiento y Análisis de Querys

1. Análisis de Querys – Los índices

Es importante saber que índice se requiere para cada tipo de operación:

B-trees : <,<=,=,>=,>, BETWEEN, IN y las condiciones IS NULL e IS NOT NULL Las búsquedas con LIKE '%algo' no usan el índice Las búsquedas con LIKE 'algo%' si usan el índice Las búsquedas con iLIKE no usan el índiceHASH : =

GiN : <@,@>,=,&&







Los índices compuestos tiene el límite de hasta 32 campos en su composición, considere al momento de las consultas usar el mismo orden de columnas con el cual creo el índice.

En versiones anteriores a la 9 de PostgreSQL, los datos NULL no se indexaban.

Podemos crear índices más complejos como por ejemplo:

●Create index idx_tabla on tabla ( campo1 || campo 2);

●Create index idx_tabla on tabla ( substr(campo1,5,10) );

●Create index idx_tabla on tabla ( upper(campo1));

Para obtener provecho de esto las consultas deben hacer el pedido de la data en la estructura en la que se ha creado el índice.







Los índices parciales nos permiten tener indexada una porción de la data de una tabla.

●Create index idx_nombre on tabla1 (campo1) where campo1 > 100 and campo1 <= 100000;

Si la búsqueda sobre esta tabla escapa a los valores especificados entonces no se usará el índice.

Podemos especificar un índice de este tipo donde los valores WHERE sean diferentes a los que estamos indexando.

●Create index idx_nombre on tabla1 (campo1) where campo2 > 100 and campo2 <= 100000;

Select * from tabla1 where campo1 = 10 and campo2 = 1000; <-- usará el índice

Select * from tabla1 where campo1 = 10; <-- no usará el índice

Select * from tabla1 where campo2 > 1000 and campo3 = 1000; <-- podría usar el índice







Se pueden aplicar ordenes especificos a los índices:

Create index idx_nombre on tabla1 ( campo1 DESC);

Create index idx_nombre on tabla1 ( campo1 ASC);

Create index idx_nombre on tabla1 ( campo1 NULLS FIRST);

Create index idx_nombre on tabla1 ( campo1 NULLS LAST);

text_pattern_ops, varchar_pattern_ops, and bpchar_pattern_ops son operadores que se usan para tipos de datos cadenas de caracteres, tiene utilidad cuando se hacen búsquedas por expresiones regulares.






1. Análisis de Querys – Explain

Explain permite visualizar el plan de ejecución de un query, el plan de ejecución son los pasos que sigue la dmbs para procesar la consulta, tabla por tabla con la que trabaja, las uniones, tipos de índices que utiliza, tuplas movidas, etc. prueba4=# explain select * from regla; QUERY PLAN Seq Scan on regla (cost=0.00..18.00 rows=800 width=72)(1 row)







Para ver los comandos usados y los tiempos de respuesta

prueba4=# explain analyze select * from regla; QUERY PLAN Seq Scan on regla (cost=0.00..18.00 rows=800 width=72) (actual time=0.012..0.016 rows=2 loops=1) Total runtime: 0.070 ms(2 rows)

Informa los campos requeridos en la consulta

prueba4=# explain verbose select * from regla; QUERY PLAN Seq Scan on public.regla (cost=0.00..18.00 rows=800 width=72) Output: id, nombre(2 rows)

prueba4=# explain analyze verbose select * from regla; QUERY PLAN Seq Scan on public.regla (cost=0.00..18.00 rows=800 width=72) (actual time=0.010..0.013 rows=2 loops=1) Output: id, nombre Total runtime: 0.050 ms(3 rows)







Los Explain siempre se deben leer de “adentro hacia afuera”.

prueba4=# explain select * from factura_cab a join factura_det b on a.id =b.fac_id; QUERY PLAN Merge Join (cost=260.93..525.73 rows=17120 width=29) Merge Cond: (b.fac_id = a.id) > Sort (cost=111.15..115.15 rows=1600 width=21) Sort Key: b.fac_id > Seq Scan on factura_det b (cost=0.00..26.00 rows=1600 width=21) > Sort (cost=149.78..155.13 rows=2140 width=8) Sort Key: a.id > Seq Scan on factura_cab a (cost=0.00..31.40 rows=2140 width=8)(8 rows)

El primer explain fue hecho sin hacer un VACUMM a las tablas, en el segundo se procedió a ello, nótese las diferencia en las cifras, esto se debe a las estadísticas.

prueba4=# explain select * from factura_cab a join factura_det b on a.id =b.fac_id; QUERY PLAN Hash Join (cost=1.07..2.16 rows=4 width=25) Hash Cond: (b.fac_id = a.id) > Seq Scan on factura_det b (cost=0.00..1.04 rows=4 width=17) > Hash (cost=1.03..1.03 rows=3 width=8) > Seq Scan on factura_cab a (cost=0.00..1.03 rows=3 width=8)(5 rows)







Para determinar si un índice debe ser utilizado, PostgreSQL debe tener estadísticas sobre la tabla. Estas estadísticas se recolectan mediante VACUUM ANALYZE, o simplemente ANALYZE. Usando las estadísticas, el optimizador sabe cuántas son las filas en la tabla, y puede determinar mejor si los índices deben utilizarse. Las estadísticas son también valiosas en la determinación de un orden óptimo y métodos de unión. La recolección de Estadísticas debe ser realiza periódicamente como el cambio de contenido de la tabla.

El costo:

(cost=149.78..155.13 rows=2140 width=8)149.78 < costo inicial de traer la primera tupla155.13 < costo total estimadoRows=2140 < filas escaneadasWidth=8 < filas de salida

El costo total estimado se calcula sobre la siguiente formula (disk pages read * seq_page_cost) + (rows scanned * cpu_tuple_cost)

seq_page_cost < costo de acceso a las páginas de la data (1.00 default)cpu_tuple_cost < costo del proceso de cada fila durante la consultas (0.01 default)







Seq Scan on factura_cab a (cost=0.00..1.03 rows=3 width=8)

Seq Scan < indica que esta llevando a cabo una busqueda secuencial en la tabla, bien porque no existe un índice o bien porque no la necesita.on factura_cab a < nos indica que esta buscando sobre la tabla “factura” con alias “a”.

Hash (cost=1.03..1.03 rows=3 width=8)

Hash < significa que esta creando un mapa de datos e índices con el Fin de facilitar búsquedas

Sort (cost=149.78..155.13 rows=2140 width=8) Sort Key: a.id

SORT KEY < nos índica por que campo esta realizando un ordenamiento y Posteriormente el costo del ordenamiento







Merge Join (cost=260.93..525.73 rows=17120 width=29) Merge Cond: (b.fac_id = a.id)

Hash Join (cost=1.07..2.16 rows=4 width=25) Hash Cond: (b.fac_id = a.id)

Tanto en el caso Merge Join como en el caso Hash Join el dbms esta realizando la unión de las dos tablas, nos indica el costo para cada caso.

Lo que tenemos que buscar siempre es que los COSTOS de nuestras consultas sean lo más bajos posibles, no siempre una búsqueda secuencial puede tener un costo mayor que una búsqueda indexada, eso dependerá de la data y estructura de las tablas.

Es importante escribir querys limpios, dar el menor trabajo posible al analizador de querys de PostgreSQL para que la resolución del plan de ejecución sea la menor posible.







Otros operadores que podemos encontrar son:

●Nested Loop < Se combinan dos tablas utilizando bucles anidados. Por cada fila de la tabla padre, se recorren todas las filas de la tabla hija.

●Index scan < búsqueda sobre un índice●Unique < elimina registros de valores duplicados●Limit < indica que se esta pidiendo una cantidad limitada de registros, aparece cuando se ha usado el operador en la consulta

●Aggregate < concatenación de columnas●Subquery Scan < indica una subconsulta dentro del contexto de un UNION●Subplan < indica una subconsulta dentro de un subquery●Append < indica que se están uniendo 2 tablas, aparece cuando se uso el operador UNION en la consulta

●Tid Scan (raro)●Group < indica que se hace un GROUP BY●Result < indica una operación que no mueve datos●Materialize < se da en caso de que existan subconsultas que se repiten y el dbms decide almacenar los resultados obtenidos para su rehuso.

http://www.iphelp.ru/faq/15/ch04lev1sec3.html



http://www.iphelp.ru/faq/15/ch04lev1sec3.html




1. Análisis de Querys

PRACTICA






2. Administración – Backup y Restore

a) pg_dump, permite generar un backup de una db específica.

pf_dump NOMBRE_DB a < solo datos pf_dump NOMBRE_DB b < incluir objetos grandes

pg_dump NOMBRE_DB c < incluye limpieza de objetos de la db, inserta drops antes De crearlos

pg_dump NOMBRE_DB C < incluye un create database

pg_dump NOMBRE_DB encoding=LATIN1 < backup con otra codificación

pg_dump NOMBRE_DB file=backup.dump < el backup se crear en este archivo

pg_dump NOMBRE_DB format=p < backup en texto plano

pg_dump NOMBRE_DB format=c < backup en formato que soporta pg_restore, comprimido

pg_dump NOMBRE_DB schema=NOMBRE_SC < backup solo del esquema especificado

pg_dump NOMBRE_DB excludeschema=NO< backup excluyendo el esquema especificado

pf_dump NOMBRE_DB o < incluir el OID de los objetos, útil solo si se usa los OID Especificamente.








pf_dump NOMBRE_DB O < no se backupean los OWNER de los objetos, es útil cuando Cuando se mueve una db de un servidor a otro diferente. pf_dump NOMBRE_DB S < solo backupea estructura de la db más no la data

pg_dump NOMBRE_DB table=NOMBRE_TAB < backupea solo la tabla especificada

pg_dump NOMBRE_DB excludetable=TA < backupea sin la tabla especificada

pg_dump NOMBRE_DB X < no se backupean los permisos

pg_dump NOMBRE_DB –compres=0..9 < especifica el nivel de compresión del backup, útil cuando Se usa el parámetro: format=c

pg_dump NOMBRE_DB inserts < genera inserts de la data en vez de copys, añadir columninserts si se desea que se especifiquen en los Insert los nombres de los campos

pg_dump NOMBRE_DB disabletriggers < desabilita los triggers, útil solo si copiamos data y no Estructura de la db.

pg_dump NOMBRE_DB notablespaces < no incluye las definiciones de los tablespaces en el backup








Todos los parámetros donde se especifican nombre de objteos (tablas, schemas, etc.) pueden usar el comodín “*”, por ejemplo todas la tabla que empiezan con EQSOFT es “table=EQSOFT*”

Todos se pueden usar solos o en combinación, además están los parametros de conexión los cuales son:

h HOST_NAME < ip del servidor o nombre del hostp PUERTO < número del puertoU USER_NAME < nombre del usuariow < no pide passwordW < fuerza a pedir el password

Se pueden usar estas variables de entorno: PGDATABASE, PGHOST, PGOPTIONS, PGPORT y PGUSER

ernesto@depeche:~/aaa$ pg_dump prueba5 > archivo.dumppg_dump: [archivador (bd)] fallÃ³ la conexiÃ³n a la base de datos Â«prueba5Â»: FATAL: no se especifica un nombre de usuario en el paquete de inicio

ernesto@depeche:~/aaa$ export PGUSER=dbadminernesto@depeche:~/aaa$ pg_dump prueba5 > archivo.dump







b) pg_dumpall, permite generar un backup de todo el dbms.

Implementa los mismos parámetros de pg_dump, añade el parámetro “l NOMBRE_DB” para especificar el nombre de la base de datos a kacupear (mejor usar pg_dump).

pg_dumpall ademas copia usuarios de la base de datos además de la data y estructura cosa que no hace pg_dump

Para comprimir un dump normal (en texto plano) podemos usar:

ernesto@depeche:~/aaa$ pg_dump prueba5 U dbadmin > dump.dumpernesto@depeche:~/aaa$ ls dump.dump larwrr 1 ernesto ernesto 24522 20101009 12:07 dump.dump

ernesto@depeche:~/aaa$ pg_dump prueba5 U dbadmin | gzip > dump.dump.gzernesto@depeche:~/aaa$ ls dump.dump.gz larwrr 1 ernesto ernesto 3940 20101009 12:06 dump.dump.gz







c) pg_restore, permite cargar un backup a la dbms, siempre y cuando el backup haya sido generado por el parámetro “format=c”

Algunas ventajas de usar pg_restore sobre el metodo alternativo es que tenemos mayor velocidad en restore de bases de datos enormes debido al uso de multihilos para el restore.

ernesto@depeche:~/aaa$ pg_dump prueba5 format=c U dbadmin > pgrestore.dump

ernesto@depeche:~/proyectos$ dropdb prueba5 U dbadminernesto@depeche:~/proyectos$ createdb prueba5 U dbadmin

ernesto@depeche:~/aaa$ pg_restore pgrestore.dump U dbadmin –dbname=prueba5

ernesto@depeche:~/aaa$ pg_dump prueba5 > otro.dump U dbadmin

ernesto@depeche:~/proyectos$ createdb prueba6 U dbadmin

ernesto@depeche:~/aaa$ pg_restore otro.dump U dbadmin dbname=prueba6pg_restore: [archivador] el archivo de entrada no parece ser un archivador vÃ¡lido







c) pg_restore

Pg_restore permite el uso de muchos parámetros, básicamente los mismos de pg_dump en sentido inverso (no baja data sino sube obviamente), la lista completa puede ser revisada aquí:http://www.postgresql.org/docs/9.0/interactive/apppgrestore.html

Para especificar cuantos hilos deseamos que se lancen en el proceso de restore usamos el parámetro j

ernesto@depeche:~/aaa$ pg_restore pgrestore.dump U dbadmin j 4 dbname=prueba8

El tiempo mejorado depende de: cantidad de data, estructura de la db, cantidad de jobs, disponibilidad de la db, etc. Eventualmente se obtendrán beneficios de 25% de reducción del tiempo hasta 85% (lo máximo reportado) de ahorro.



http://www.postgresql.org/docs/9.0/interactive/app-pgrestore.html





d)¿Backups incrementales?No existe funcionalidad para ello en la versión de serie de PostgreSQL

Pgrmanhttp://code.google.com/p/pgrman/

Otra opción es hacer backups “online” de los archivos WAL.http://www.postgresql.org/docs/9/static/continuousarchiving.html

Los archivos WAL son los intercambios de data transaccional en la base de datos a nivel binario, no es necesariamente consistente el backup.



http://code.google.com/p/pg-rman/

http://www.postgresql.org/docs/9/static/continuous-archiving.html




3. Administración – Procesos

a)TOP y HTOP

TOP es un comando convencional de Linux / Unix que nos permite ver los procesos que se ejecutan en el servidor.

Los procesos ejecutados por PostgreSQL son normalmente ejecutados por los usuarios “postgres”, “pgsql” ó “postmaster”.

ernesto@depeche:~/aaa$ ps aux | egrep postgrespostgres 961 0.0 0.1 101580 2228 ? S Oct08 0:06 /usr/lib/postgresql/8.4/bin/postgres D /var/lib/postgresql/8.4/main c config_file=/etc/postgresql/8.4/main/postgresql.confpostgres 989 0.0 0.3 101704 6208 ? Ss Oct08 0:11 postgres: writer process postgres 990 0.0 0.0 101580 568 ? Ss Oct08 0:08 postgres: wal writer process postgres 991 0.0 0.0 102380 1320 ? Ss Oct08 0:09 postgres: autovacuum launcher process postgres 992 0.0 0.0 73704 848 ? Ss Oct08 0:17 postgres: stats collector process

Recuerde que PostgreSQL maneja un procesador por conexión, si tiene varios procesadores un proceso lanzado no usará varios procesadores, solo uno, deja los otros disponibles para otras conexiones que lanzan sus propios procesos, la ventaja del uso de esta funcionalidad se complementa con la capacidad de administración de usuarios concurrentes que tenga el sistema operativo que se está usando (que soporte SMP).

Nunca mate un proceso que demora mucho







b)PG_TOPhttp://ptop.projects.postgresql.org/El paquete instalador en Ubuntu es PTOP e instala la aplicación pg_top.

ernesto@depeche:~/aaa$ pg_top helppg_top: invalid option ''pg_top version 3.6.2Usage: pg_top [ITWbcinqu] [x x] [s x] [o field] [z username] [p PORT] [U USER] [d DBNAME] [h HOSTNAME] [number]

ernesto@depeche:~/aaa$ pg_top U dbadmin d prueba5

En una consola:prueba5=# begin;prueba5=# lock alumnos in exclusive mode;

En otra Consola:prueba5=# insert into alumnos values(5,'chicho',12,'nada');

PgTop nos muestra:ast pid: 29499; load avg: 1.59, 1.59, 1.69; up 1+03:48:24 3 processes: 3 sleepingCPU states: 47.0% user, 2.6% nice, 8.8% system, 40.5% idle, 1.1% iowaitMemory: 1920M used, 81M free, 26M buffers, 659M cachedSwap: 375M used, 1532M free, 45M cached PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND29500 postgres 20 0 102M 4232K sleep 0:00 0.02% 0.20% postgres: dbadmin prueba5 [local] idle 29215 postgres 20 0 102M 5048K sleep 0:00 0.00% 0.00% postgres: dbadmin prueba5 [local] idle in transaction 29396 postgres 20 0 102M 3628K sleep 0:00 0.00% 0.00% postgres: dbadmin prueba5 [local] INSERT waiting



http://ptop.projects.postgresql.org/





b)PG_TOP

A < permite ver el plan de ejecución de un query, especifique el PID del procesoC < activa/desactiva colorc < permite ver la linea de comandos completaD < cambia página de listadoh ó ? < helpE < ver versión actualizada del plan de ejecucióne < permite ver errores del sistemaI < ver/no ver procesos en espera o durmiendoK < mata un proceso, indicar el pidL < permite ver los locs del proceso, especificar el pidM < ordena por uso de memoriaN < ordena por número de proceson ó # <indica cuantos procesos se pueden ver, máximo 65O < cambia el orden de muestra dependiendo un parámetro especial ("cpu", "res", "size", "time", "seq_scan", "seq_tup_read", "idx_scan", "idx_tup_fetch", "n_tup_ins","n_tup_upd", "n_tup_del")P < ordena por utilización del procesoQ < muestra el query, especificar el pidq < QuitR < Display user table statistics.r < ??s < cambia la cantidad de segundos de refresco de la pantallaT < ordena por tiempo de ejecuciónT < ??U < muestra los procesos de un usuario, ingresar el usuario X < muestra las estadísticas de los índices






4. DBLinks

PostgreSQL no permite acceder de manera transparente entre la data de un servidor y otro, para ello se requiere crear una conexión entre ambos servidores.

Tome en cuenta uan cosa, acceder a otra db desde la cual se esta trabajando y operar sobre ella requerirá que PostgreSQL jale toda la data de las tablas que involucren la operación, luego el dbms filtrará la necesaria en la db actual pero solo después de haber jalado todo.

DbLink no viene por defecto, es necesario instalar el paquete “contrib” de la versión que estemos usando, instalado este paquete requerimos ejecutar el siguiente script:

prueba5=# \i /usr/share/postgresql/8.4/contrib/dblink.sql

a) CREATE FOREIGN DATA WRAPPER

Creamos una fuente de datos externa, solo el super usuario puede realizar esta acción.

Prueba5=# CREATE FOREIGN DATA WRAPPER dw_prueba VALIDATOR postgresql_fdw_validator;

VALIDATOR postgresql_fdw_validator esta predeterminado para chequear la consistencia de la conexión, si no se especifica esto no se validará la misma.






4. DBLinks

b) CREATE SERVER

Con está sentencia creamos el servidor al cual nos vamos a conectar

prueba5=# CREATE SERVER srv_prueba FOREIGN DATA WRAPPER dw_prueba OPTIONS (hostaddr '127.0.0.1', dbname 'drupal7',port '5432');

c) CREATE USER MAPPING

Creamos un usuario de conexión a la db foranea.

prueba5=# CREATE USER MAPPING FOR dbadmin SERVER srv_prueba OPTIONS (user 'usuario_foraneo', password 'password_foraneo');

Dbadmin < es el usuario/rol al cual le vamos a dar acceso al servidorusuario_foraneo < es el usuario que tiene acceso a la db foráneapassword_foraneo < clave

d) SELECT dblink_connect

Antes de poder usar la el dblink necesitamos conectarnos:

prueba5=# SELECT dblink_connect('mi_conexion','srv_prueba');






4. DBLinks

e)Probando la conexión:

prueba5=# select dblink_exec('mi_conexion','create table tbl_pruebas(id serial,nombre varchar(100))'); dblink_exec CREATE TABLE

prueba5=# select dblink_exec('mi_conexion','insert into tbl_pruebas (nombre) values (''ernesto'')'); dblink_exec INSERT 0 1

prueba5=# select dblink_exec('mi_conexion','insert into tbl_pruebas (nombre) values (''juan'')'); dblink_exec INSERT 0 1

ernesto@depeche:~$ psql drupal7 U dbadmin psql (8.4.4) Digite «help» para obtener ayuda. drupal7=# select * from tbl_pruebas; id | nombre + 1 | ernesto 2 | juan (2 filas) drupal7=#






4. DBLinks

f)Trayendo Data:

prueba5=# select* from dblink('mi_conexion','select * from tbl_pruebas') as (f_id integer, f_nomber varchar(100)); f_id | f_nomber + 1 | ernesto 2 | juan(2 filas)

Para conocer más sobre las funciones de dblink http://www.postgresql.org/docs/9/static/dblink.html



http://www.postgresql.org/docs/9/static/dblink.html




5. Vacuum

El Vacuum es una de las más importantes tareas de administración, lo que hace es limpiar las “páginas” no usadas por el sistema y actualiza las estadísticas de las tablas e índices para una mejor resolución de querys.

La dbms ejecuta periodicamente (definido en postgresql.conf) un Lazy Vacuum, esto es libera páginas no usadas por data, más no por índice, este vacuum no genera demasiado tiempo de bloqueo en la tabla (depende el tamaño).






5. Vacuum

El full vacuum requiere acceso exclusivo a la tabla durante el tiempo que demoré la operación, esta limpiara totalmente las páginas no usadas.

Mejora notablemente el tiempo de acceso a los datos.






5. Vacuum

Se pueden aplicar Vaccums a nivel de tabla o base de datos.

●Vacuum full TABLA < limpia todo el espacio no utilizado, reescribe totalmente la tabla por lo cual consume más espacio.

●Vacuum analyze TABLA < actualiza las estadísticas para e generador de plan de ejecución.

●Vacuum TABLA < solo limpia data y reorganiza las páginas.

Se puede añadir de precisión un Vacuum sobre un campo.

“Vacuumdb” se utiliza externamente desde la linea de comandos del sistema operativo para ejecutar la operación sobre la base de datos seleccionada.

ernesto@depeche:~$ vacuumdb full prueba5 U dbadmin



Curso de PostgreSQL

Education

Transcript of Curso de PostgreSQL