A pesar que desde Mysql 5 existe el catálogo con la metadata de las bases de datos, para quienes venimos desde versiones previas, el uso de funciones como show tables y describe han sido casi fundamentales al momento de trabajar con la base de datos.

Para quienes no conozcan los comandos, el primero nos lista las tablas que existen en nuestra base de datos, y el segundo, pasándole como valor el nombre de una tabla, nos muestra qué columnas tiene, con qué tipo de datos, información de los índices y algunos campos más.

Vayamos a los ejemplos usando una la base de datos de Magento.

mysql> show tables;
+--------------------------------------------+
| Tables_in_magento                          |
+--------------------------------------------+
| admin_assert                               |
| admin_role                                 |
| admin_rule                                 |
| admin_user                                 |
| adminnotification_inbox                    |
| amazonpayments_api_debug                   |
| api_assert                                 |
| api_role                                   |
| api_rule                                   |
| api_session                                |
| api_user                                   |
| catalog_category_entity                    |
| ...                                        |
+--------------------------------------------+

La cantidad de tablas es bastante más amplia, para el ejemplo mostramos sólo una parte.

Ahora bien, tengo que hacer una consulta que me devuelva sólo algunos valores, pero no recuerdo bien los campos. Aquí es donde describe nos va a ayudar. Supongamos que es la tabla catalog_category_entity la que necesitamos usar y no sabemos nada de sus campos.

mysql> describe catalog_category_entity;
+------------------+----------------------+------+-----+---------------------+----------------+
| Field            | Type                 | Null | Key | Default             | Extra          |
+------------------+----------------------+------+-----+---------------------+----------------+
| entity_id        | int(10) unsigned     | NO   | PRI | NULL                | auto_increment |
| entity_type_id   | smallint(8) unsigned | NO   |     | 0                   |                |
| attribute_set_id | smallint(5) unsigned | NO   |     | 0                   |                |
| parent_id        | int(10) unsigned     | NO   |     | 0                   |                |
| created_at       | datetime             | NO   |     | 0000-00-00 00:00:00 |                |
| updated_at       | datetime             | NO   |     | 0000-00-00 00:00:00 |                |
| path             | varchar(255)         | NO   |     | NULL                |                |
| position         | int(11)              | NO   |     | NULL                |                |
| level            | int(11)              | NO   | MUL | NULL                |                |
| children_count   | int(11)              | NO   |     | NULL                |                |
+------------------+----------------------+------+-----+---------------------+----------------+
10 rows in set (0.00 sec)

Como ven, nos da el detalle de la tabla y ahora si, no sólo conocemos los campos posibles, sino el tipo de dato y si tienen algún índice.

De aquí en más, será bastante más sencillo seguir trabajando con nuestros queries.

Hasta acá todo muy lindo pero, como decía al comienzo, cuando toca trabajar con PostgreSql éstas dos funciones se extrañan; aunque gracias a la metadata que nos brinda, podemos resolver ésto con algunas consultas al information_schema.

Si bien sólo voy a abordar la forma de emular las dos funciones que mencioné, seria recomendable que hagan una revisión completa para conocer mejor la información que puede obtenerse.

Vamos con el primer caso: obtener la lista de tablas de una base de datos.

SELECT
  TABLES.TABLE_NAME,
  pg_description.description
FROM
  information_schema.TABLES
  LEFT JOIN
    pg_class ON TABLES.TABLE_NAME::name = pg_class.relname
  LEFT JOIN
    pg_description ON pg_class.oid = pg_description.objoid AND pg_description.objsubid = 0
WHERE
  TABLES.table_schema::text = 'public'::text AND TABLES.table_type = 'BASE TABLE'::text
ORDER BY
  TABLES.TABLE_NAME ASC;

El resultado de ésta consulta, será lo siguiente:

        table_name         |                   description
---------------------------+-------------------------------------------------
 errores                   | Errores del servidor
 logs                      | Logs de tareas de backend del sistema
(2 rows)

A diferencia de lo que se obtiene con la versión original de Mysql, en el caso de PostgreSql he agregado el comentario de la tabla, pero es un detalle personal y dependerá de que tengan los comentarios.

Otra aclaración es que el show tables de Mysql devuelve tanto tablas como vistas. En la consulta que hicimos en PostgreSql, he filtrado para que sólo devuelva las tablas (es la condición que indica tables.table_type = ‘BASE TABLE’). Si quisiéramos que en PostgreSql nos muestre las vistas, o bien deberíamos aplicarlo a la condición o bien quitar el filtro de tipo de tabla.

La segunda función a simular es la que nos describe la composición de una tabla. Nuevamente, vamos a recurrir a una consulta y me voy a basar en la tabla errores que me devolvió la consulta anterior.

SELECT
  COLUMNS.column_name,
  COLUMNS.data_type,
  COLUMNS.column_default,
  COLUMNS.is_nullable,
  COLUMNS.character_maximum_length,
  COLUMNS.numeric_precision,
  pg_description.description,
  COLUMNS.TABLE_NAME
FROM
  information_schema.COLUMNS
  LEFT JOIN
    pg_class ON COLUMNS.TABLE_NAME::name = pg_class.relname
  LEFT JOIN
    pg_description ON pg_class.oid = pg_description.objoid AND COLUMNS.ordinal_position::INTEGER = pg_description.objsubid
WHERE
  COLUMNS.table_schema::text = 'public'::text
  AND
  COLUMNS.TABLE_NAME = 'errores'
ORDER BY
  COLUMNS.TABLE_NAME ASC,
  COLUMNS.ordinal_position ASC
;

El resultado de ésta consulta, que aplica una condición pidiendo solo los campos de una tabla determinada, seria el siguiente.

   column_name   |          data_type          |             column_default           | is_nullable | character_maximum_length | numeric_precision | description | table_name
-----------------+-----------------------------+--------------------------------------+-------------+--------------------------+-------------------+-------------+------------
 id              | integer                     | nextval('seq_ierrores_id'::regclass) | NO          |                          |                32 |             | errores
 fecha           | timestamp without time zone |                                      | YES         |                          |                   |             | errores
 usuario         | character varying           |                                      | YES         |                       50 |                   |             | errores
 nerror          | character varying           |                                      | YES         |                      100 |                   |             | errores
 descripcionasp  | character varying           |                                      | YES         |                      255 |                   |             | errores
 categoria       | character varying           |                                      | YES         |                      255 |                   |             | errores
 columna         | smallint                    |                                      | YES         |                          |                16 |             | errores
 descripcion     | character varying           |                                      | YES         |                      255 |                   |             | errores
 archivo         | character varying           |                                      | YES         |                      255 |                   |             | errores
 linea           | smallint                    |                                      | YES         |                          |                16 |             | errores
 numero          | bigint                      |                                      | YES         |                          |                64 |             | errores
 codigofuente    | character varying           |                                      | YES         |                      255 |                   |             | errores
 revisado        | boolean                     | false                                | YES         |                          |                   |             | errores
 usuariorevision | smallint                    |                                      | YES         |                          |                16 |             | errores
 fecharevision   | timestamp without time zone |                                      | YES         |                          |                   |             | errores
(21 rows)

Si prestan atención, ya tenemos los mismos resultados (detalle más, detalle menos) que obteníamos al comienzo con funciones nativas.

Sólo restan un par de aclaraciones. La última consulta trajo solamente los campos de una tabla determinada porque aplicamos un filtro. Habitualmente, lo que suelo hacer es crear, al menos, dos vistas con éstas consultas. En el caso del último ejemplo, no aplico filtro en la consulta, pero al momento de seleccionar la vista, aplicamos una condición donde filtramos por la tabla que queremos consultar.

A lo mejor te interese leer

• Update con Subselect en Mysql
• Restaurar un backup plano en PostgreSql
• Cómo crear un trigger con un Definer específico en Mysql
• Backup de tablas específicas en PostgreSql
• Duplicando una tabla en Mysql

Ahora bien, cómo ¿hacemos para volver a introducir esos datos?.

Simplemente basta con ejecutar este comando:

psql -U usuario -d basededatos -h host -f archivoplano.sql

Automáticamente se nos pedirá la contraseña

Password for user usuario:

Una vez ingresada, nuestros datos pasarán a insertarse en PostgreSql.

A lo mejor te interese leer

• Backup de tablas específicas en PostgreSql
• Restaurar backups de PostgreSql
• Automatizar backups de PostgreSql
• Backup de bases de datos en PostgreSql
• Simulando show tables y describe de Mysql en PostgreSql

Hace unos días tuve un requerimiento por el cual, si bien la base de datos en cuestión ya se backupea, me solicitaban hacer un backup con mayor periodicidad, pero sólo de un conjunto de tablas.

Bien, gracias a la flexibilidad de nuestro motor favorito, esto es muy sencillo.

Repasemos cómo hacíamos para hacer un dump completo de nuestro base de datos.

pg_dump -i -h localhost -p 5432 -U postgres -F c -b -v -f "/home/damian/backups/mibase.backup" mibase

Para exportar sólo un conjunto de tablas, tenemos que hacer un pequeño cambio.

pg_dump -i -h localhost -p 5432 -U postgres -t tabla -F p -b -v -f "/home/damian/backups/mitabla.sql" mibase

La diferencia entre ambos scripts radica en que agregamos el parámetro -t seguido del nombre de nuestra tabla (en este caso, con poca inspiración, usé tabla).

Lo que vamos a obtener es, solamente,  un backup de la tabla indicada, con su estructura y datos.

Si lo que necesitamos son un conjunto de tablas, tenemos dos formas de hacerlo.  La primera es usando el parámetro -t tantas veces como tablas vayamos a requerir.

pg_dump -i -h localhost -p 5432 -U postgres -t usuarios -t documentos -t logs -F p -b -v -f "/home/damian/backups/mistablas.sql" mibase

La segunda forma, es utilizar patrones (si es que se aplica a nuestro caso).

pg_dump -i -h localhost -p 5432 -U postgres -t productos_* -F p -b -v -f "/home/damian/backups/mistablas.sql" mibase

En ambos casos, se hará un backup de las tablas, vistas y/o secuencias que coincidan con lo indicado.

Llegado el caso, podríamos combinar ambos ejemplos y generar algo parecido a esto.

pg_dump -i -h localhost -p 5432 -U postgres -t usuarios_* -t documentos_* -t logs_* -F p -b -v -f "/home/damian/backups/mistablas.sql" mibase

De ésta forma obtendríamos todas las tablas (y/o vistas y/o secuencias) que comienzen con usuarios_, documentos_ y logs_.

Hay que tener en cuenta que al usar ésta técnica, pg_dump no intentará obtener aquellos objetos de los cuales puedan depender nuestras tablas. Es por eso que no se da garantía de que pueda restaurarse sin problemas éste backup.

Si prestan atención, comparando con el primer ejemplo que hace un backup total de la base de datos, hice un cambio al parámetro -F, pasándole como valor p en lugar de c. Lo que hace este cambio es devolver el backup en formato plano y no comprimido.

Otro escenario posible es que, en lugar de querer backupear ciertas tablas, quieren obtener todas, menos algunas. Ésto también es posible, sólo debemos hacer otro pequeño cambio.

El ejemplo sería el siguiente.

pg_dump -i -h localhost -p 5432 -U postgres -T productos_* -F p -b -v -f "/home/damian/backups/mibase.sql" mibase

El parámetro -T es el que se encarga de excluir una tabla. De ésta forma, el ejemplo anterior haría un backup completo, pero sin las tablas indicadas.

El tercer escenario, sería la combinación de ambos parámetros.

El comportamiento en este caso varía un poco. Vamos con un ejemplo.

pg_dump -i -h localhost -p 5432 -U postgres -T *productos -t documentos_* -t logs_* -F p -b -v -f "/home/damian/backups/mistablas.sql" mibase

Con ambos parámetros presentes, lo que se obtiene es un backup de los objetos indicados en -t pero que no coincidan con el patrón que toma -T.

Según el ejemplo, se hará backup de todas las tablas que comiencen con documentos_ y logs_, pero se excluirán todas aquellas que terminen con productos. Es decir que si existiera una tabla llamada logs_productos, ésta no será backupeada.

De más está decir que nunca hay que dejar de repasar la documentación oficial y hacer las pruebas necesarias antes de llevar algo a producción.

A lo mejor te interese leer

• Restaurar un backup plano en PostgreSql
• Restaurar backups de PostgreSql
• Automatizar backups de PostgreSql
• Backup de bases de datos en PostgreSql
• Simulando show tables y describe de Mysql en PostgreSql

Hasta ahora ya habíamos visto cómo hacer un backup en Postgresql, y también, cómo hacerlo de manera automática.

Vamos ahora a la otra punta del circuito: restaurar una base desde nuestros backups.

El comando que vamos a utilizar (y conocer) es pg_restore.

Si lo aplicara a los ejemplos que antes dí sobre pg_dump, nuestro ejemplo de pg_restore seria el siguiente.

pg_restore -i -h localhost -p 5432 -U postgres -d mibase -v "/home/damian/backups/mibase.backup"

Una vez que lo ejecutemos, se nos pedirá la contraseña del usuario que vamos a usar.

Para conocer los parámetros que podemos pasarle al comando, nada mejor que darse una vuelta por la documentación oficial, ya que hay algún que otro detalle que estaría bueno conocer (y además, porque es buena práctica leer la documentación oficial).

Sobre los parámetros del ejemplo, paso a detallarlos.

• -i le indica que ignore la versión (entre el comando y la base de datos).
• -h localhost es el host de nuestro PostgreSql.
• -p 5432 es la indicación del puerto donde corre el servicio.
• -U postgres especifica que se usará el usuario postgres para la operación.
• -d mibase es para que realize la restauración sobre una base de datos en particular, en este caso mibase.
• -v ejecutará el comando en modo verbose (así podremos ir viendo la salida de cada paso del proceso).
• /home/damian/backups/mibase.backup es el archivo que usaremos como backup y que queremos ingresar.

Hasta ahora, ya hemos podido realizar backups, automatizarlos, y ahora, ya podremos restaurar nuestras bases de datos desde la consola sin problemas.

Una recomendación para los que estén empezando a conocerse con PostgreSql, es suscribirse a la lista de correo en español.

Es bastante activa, y tiene integrantes ante los cuales hay que sacarse el sombrero, tanto por el conocimiento como por la colaboración que brindan.

A lo mejor te interese leer

• Restaurar un backup plano en PostgreSql
• Backup de tablas específicas en PostgreSql
• Automatizar backups de PostgreSql
• Backup de bases de datos en PostgreSql
• Simulando show tables y describe de Mysql en PostgreSql

Ahora bien, ¿cómo saber cuánto pesa tu base de datos en PostgreSql?. Bastante fácil, con la siguiente consulta.

SELECT pg_database.datname, pg_size_pretty(pg_database_size(pg_database.datname)) AS SIZE FROM pg_database;

De ésta forma, conseguimos los tamaños de nuestras bases y vemos algo como lo siguiente.

  datname  |  size
-----------+---------
 template1 | 4336 kB
 template0 | 4248 kB
 postgres  | 4336 kB

Si quisieras obtener el tamaño de alguna base en particular, será cuestión de agregarle la condición y preguntar por el nombre de la base buscada.

Así de rápido termina este pequeño tip.

A lo mejor te interese leer

• Simulando show tables y describe de Mysql en PostgreSql
• Restaurar un backup plano en PostgreSql
• Backup de tablas específicas en PostgreSql
• Restaurar backups de PostgreSql
• Automatizar backups de PostgreSql

Si por casualidad el primer pensamiento es poner las instrucciones para pg_dump en un script, lamento desilusionar. Tendríamos un pequeño problema, y es que el comando se quedará frenado pidiéndonos la contraseña del usuario que quiere hacer el backup.

Como siempre, tenemos una salida.

Nuestro nuevo mejor amigo en este caso será pgpass.

Pgpass es una variable de entorno.

Este archivo no se crea por defecto, y varía levemente el procedimiento si lo usamos en Linux o en Windows. En ambos casos, el archivo contendrá la misma información:

host:puerto:basededatos:usuario:contraseña

Caso Windows

Para usarlo, debemos crear la carpeta postgresql dentro de c:\documents and settings\(usuario que correrá la tarea)\datos de programa.

Dentro de esa nueva carpeta, pondremos el archivo pgpass.conf.

Ahora si, dentro del archivo, podríamos tener los siguientes parámetros:

192.168.0.1:5432:mibase:miusuario:micontraseña

Caso Linux

En mi ejemplo, el encargado de realizar el backup será nuestro querido root.

Para que funcione, siempre y cuando tengamos los privilegios, vamos dentro de la carpeta /root y creamos el archivo .pgpass.

Una forma rapida, y presuponiendo que estamos logueados como root, sería la siguiente.

echo "192.168.0.1:5432:mibase:miusuario:micontraseña" >> ~/.pgpass

Si todo salió bien, ya tenemos creado el archivo.

¿Y ahora?.

Bueno, ya tenemos resuelto el detalle de la contraseña. Ahora, simplemente, creamos un archivo que será el que vamos a programar para que se ejecute automaticamente y nos realize el backup.

Dentro de nuestro script pondremos el comando:

pg_dump -i -h 192.168.0.1 -p 5432 -U miusuario -F c -b -v -f "/home/damian/backups/mibase.backup" mibase

Ahora cuando el script necesite la contraseña para conectarse, la tomará del Pgpass… y asunto resuelto.

A lo mejor te interese leer

• Backup de bases de datos en PostgreSql
• Restaurar un backup plano en PostgreSql
• Backup de tablas específicas en PostgreSql
• Restaurar backups de PostgreSql
• Simulando show tables y describe de Mysql en PostgreSql

Lo siguiente, es la descripción de cómo podemos lograr un dump nuestro PostgreSql desde la línea de comandos.

pg_dump -i -h localhost -p 5432 -U postgres -F c -b -v -f "/home/damian/backups/mibase.backup" mibase

Ahora bien, empezemos a ver qué estamos haciendo y con que nos estamos encontrando.

En primer lugar, cuando querramos ejecutar este comando, nos va a pedir la contraseña para el usuario con el cual lo estamos queriendo ejecutar (usuario postgres en este caso). Entonces, ingresamos la contraseña, Enter, y comienza el proceso.

Prestemos atención al comando completo:

pg_dump -i -h localhost -p 5432 -U postgres -F c -b -v -f "/home/damian/backups/mibase.backup" mibase

Veamos qué significan cada uno de los parametros que estamos indicando.

• pg_dump es el comando en si mismo.
• -i le indica que ignore la versión (entre el comando y la base de datos).
• -h localhost especifica el host del motor de base de datos (localhost en este caso).
• -p 5432 es la indicación del puerto donde corre el servicio.
• -U postgres es para indicarle que usaremos el usuario postgres.
• -F indica el formato de salida.
• c es la elección del formato (comprime en este caso).
• -b indica que vuelque los LO (large objects).
• -v verbose.
• -f es el archivo de salida.
• /home/damian/backups/mibase.backup es el nombre para el archivo de salida (con path).
• mibase es el nombre de la base a backupear.

De mas está aclarar, que siempre debemos recurrir a la fuente, así que nada mejor que visitar la documentación oficial.

A manera de yapa, si en lugar de utilizar Linux, aplicamos el ejemplo en Windows, habrá que hacerle los siguientes arreglos al comando:

C:\Archivos de programa\PostgreSQL\8.3\bin\pg_dump.exe -i -h localhost -p 5432 -U postgres -F c -b -v -f "C:\mibase.backup" mibase

Nótese que fue necesario indicar el path completo al binario.

A lo mejor te interese leer

• Automatizar backups de PostgreSql
• Restaurar un backup plano en PostgreSql
• Backup de tablas específicas en PostgreSql
• Restaurar backups de PostgreSql
• Simulando show tables y describe de Mysql en PostgreSql