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

El truco para ésto es utilizar subconsultas.

Lo más probable es que al pensar en esto, escriban un ejemplo como el siguiente:

UPDATE
  tabla1
SET
  campo = 'nuevo_valor'
WHERE
  campo_de_referencia = (
    SELECT
      tabla1.valor
    FROM
      tabla1,
      tabla2
    WHERE
      tabla1.campo = 'viejo_valor'
      AND
      tabla1.clave_primaria = tabla2.clave_foranea
      AND
      tabla2.campo_de_referencia = 'otro_valor'
  )
;

Lamentablemente, ésto no va a funcionar y van a obtener el siguiente error.

You can't specify target table 'tabla1' for update in FROM clause

Esto se debe a que como restricción, no puede actualizarse una tabla y al mismo tiempo hacer una consulta sobre si misma.

¿Cuál es la solución entonces?, utilizar un alias para la subconsulta.

UPDATE
  tabla1
SET
  campo = 'nuevo_valor'
WHERE
  campo_de_referencia = (
    SELECT
      valor
    FROM
      (
        SELECT
          tabla1.valor
        FROM
          tabla1,
          tabla2
        WHERE
          tabla1.campo = 'viejo_valor'
          AND
          tabla1.clave_primaria = tabla2.clave_foranea
          AND
          tabla2.campo_de_referencia = 'otro_valor'
      )
    AS alias_tabla1
  )
;

Ahora si, nuestra subconsulta queda encerrada en un alias, y ese alias es el que se aplica para la subconsulta en el update.

A lo mejor te interese leer

• Simulando show tables y describe de Mysql en PostgreSql
• Cómo crear un trigger con un Definer específico en Mysql
• Duplicando una tabla en Mysql
• Cambiando el Definer de un Procedure en Mysql
• Convirtiendo de Timestamp a Date desde 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

Es en ese pasaje cuando descubrimos que el usuario que tenemos asignado está totalmente restringido sólo a nuestra base de datos, y hay ciertas operaciones que pueden resultar imposibles de resolver.

Un escenario posible seria al intentar crear un trigger, obtengamos un error por falta de privilegios.

Si además de éste usuario, podemos acceder a uno con privilegios más elevados (el usuario root es el habitual), podríamos crear el trigger.

Esto tampoco nos va a servir, porque cuando el usuario sin privilegios quiere ejecutar el trigger, le será negada la operación ya que el propietario del trigger es quien lo creó (en este coloquial ejemplo, sería propiedad del usuario root).

Ahora bien, la forma de poder crear un trigger pero asignándole un propietario que no se corresponde con el usuario que esté ejecutando, seria la siguiente:

CREATE DEFINER = 'usuario'@'host' TRIGGER mi_trigger BEFORE INSERT ON mi_tabla
  FOR EACH ROW BEGIN
 
  /* El código que tengamos que usar */
 
END;

De ésta forma, al crearlo con el usuario con privilegios, vamos a poder ejecutar la sentencia de creación del trigger y éste va a estar disponible para el usuario restringido que le indiquemos.

(Más que post esto parece un post-it)

A lo mejor te interese leer

• Cambiando el Definer de un Procedure en Mysql
• Simulando show tables y describe de Mysql en PostgreSql
• Update con Subselect en Mysql
• Duplicando una tabla en Mysql
• Convirtiendo de Timestamp a Date desde Mysql

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

Una forma rápida de hacer esa prueba sin afectar los datos, es hacer una copia de la tabla.

En realidad, si tenemos tiempo siempre será más cómodo llevar esos datos a un entorno de staging para trabajar más tranquilos; vamos a pensar que no tenemos tiempo… y mucho menos un entorno se staging.

Si queremos duplicar nuestra tabla, sólo debemos ejecutar la siguiente instrucción:

CREATE TABLE tabla_nueva LIKE tabla_original;

De ésta forma. obtenemos una tabla idéntica en cuanto a estructura.

Si necesitamos los datos de esa tabla en nuestra copia, insertamos todos los registros de la original de la siguiente forma:

INSERT INTO tabla_nueva SELECT * FROM tabla_original;

Al haber una correspondencia exacta en cuanto a las columnas y tipos de datos, los registros son insertados sin mayor problema.

Hay una segunda forma de obtener el mismo resultado que las dos consultas previas. Podemos, con una sola instrucción, lograr la misma tabla.

En este caso, debemos ejecutar:

CREATE TABLE tabla_nueva SELECT * FROM tabla_original;

Con esto, dos formas muy rápidas de duplicar una tabla y, si se quiere, sus datos.

A lo mejor te interese leer

• Simulando show tables y describe de Mysql en PostgreSql
• Update con Subselect en Mysql
• Cómo crear un trigger con un Definer específico en Mysql
• Cambiando el Definer de un Procedure en Mysql
• Convirtiendo de Timestamp a Date desde Mysql

Hubo un pequeño error a causa de la falta de control (tanto de nuestro lado como del de los implementadores), y cuando se importó la base de datos, se crearon los Procedure con un usuario propietario que no era el mismo que teníamos para acceder a la base de datos.

Luego de lidiar un rato, logramos que nos facilitaran el usuario root de Mysql, y ahí fue otro cantar.

Antes de conseguir el usuario, uno de los caminos era arreglar el script sql y mandarlo nuevamente para que se borrara la base de datos y se volviera a importar.

Si bien cumple su cometido, hay otro aún más sencillo e igual de efectivo.

Ya con un usuario con los permisos necesarios, para conocer qué Procedures tenemos definidos en nuestras bases de datos dentro de Mysql, sólo es necesario correr ésta consulta.

SELECT * FROM mysql.proc;

Así veremos todos los que tengamos definidos, sin importar ninguna condición.

Para el problema que se había presentado, había que modificar el propietario (Definer) de esas funciones. Por suerte, nada que un par de queries no puedan arreglar.

Lo primero es aislar el set de registros que vamos a modificar, al menos, como seguridad.

Para eso, corremos esta consulta.

SELECT * FROM mysql.proc WHERE definer = 'usuario1@dominio1';

Vamos a ver todos las funciones que están definidas con ese usuario como propietario.

Ahora, para cambiarlo, alcanza con hacer un update a esos registros. En nuestro ejemplo, correríamos ésta otra consulta.

UPDATE mysql.proc SET definer = 'usuario2'@'dominio2' WHERE definer = 'usuario1@dominio1';

Y para finalizar, hacemos efectivos los cambios en los privilegios.

FLUSH PRIVILEGES;

Asunto resuelto, ya tenemos arreglado este pequeño problema de permisos.

A lo mejor te interese leer

• Cómo crear un trigger con un Definer específico en Mysql
• Simulando show tables y describe de Mysql en PostgreSql
• Update con Subselect en Mysql
• Duplicando una tabla en Mysql
• Convirtiendo de Timestamp a Date desde Mysql

La pregunta se refería a cómo pasar una fecha en formato Timestamp al formato Date (una representación más humana).

Lo primero que pensé fue en usar Php (por asumir qué así lo quería hacer), pero no, lo que quería era sacar el registro, directamente desde la base de datos, aplicando la conversión en el propio Mysql al momento de la consulta.

Como ya me ha pasado en otras ocasiones, supuse que encontraría en la documentación alguna función mágica que resolviera el problema… y por suerte, no me equivoqué.

Para convertir directamente desde la consulta una fecha desde timestamp a date, sólo hay que aplicar la siguiente función:

select from_unixtime(1224815188);

El resultado que obtenemos es:

2008-10-24 00:26:28

Nada más, con eso, problema resuelto.

Para más referencias sobre funciones de fecha, pueden mirar en la documentación oficial.

(Otro post cortito y al pié).

A lo mejor te interese leer

• Simulando show tables y describe de Mysql en PostgreSql
• Update con Subselect en Mysql
• Cómo crear un trigger con un Definer específico en Mysql
• Duplicando una tabla en Mysql
• Cambiando el Definer de un Procedure en Mysql

La forma de restaurar una base de datos Mysql desde la consola, tomando un backup, sería asi.

mysql -u usuario -p basededatos < basededatos.sql

El escenario que estoy suponiendo, implica que la base de datos que están queriendo importar no existe en su servidor Mysql.

Si este supuesto es correcto, se van a encontrar con un problemita, o mejor dicho, con un mensaje al ejecutar el comando.

ERROR 1049 (42000): Unknown database 'basededatos'

Esto se debe a la inexistencia de la base dentro de nuestro Mysql.

Tenemos dos maneras de resolver ésta situación.

1. Editar el archivo sql y agregarle a mano los comandos necesarios para la creación de la base.
2. Agregar dos parámetros a nuestro comando mysqldump.

En el primer caso, deberíamos agregar a nuestro archivo, las siguientes instrucciones.

CREATE DATABASE basededatos;
USE DATABASE basededatos;

Con esto, el script funcionaría correctamente. Lo malo de ésta forma, es que si tenemos backups muy muy pesados, puede resultar algo engorroso estar editándolos.

Para evitarnos este paso, vamos a cambiar la forma de ejecutar mysqldump.

Lo habitual y más simple para hacer el backup sería ejecutar el comando de ésta forma.

mysqldump -hhost -uusuario -ppassword basededatos > basededatos.sql

Como ya dije, esto no nos funcionará correctamente. Así que vamos a sumar algunos parámetros para estar más tranquilos.

Los parámetros en cuestión son:

• databases
• add-drop-database

Con databases mysqldump agregará automáticamente las instrucciones de creación y uso de base de datos.

Ahora bien, podría darse que por algún motivo, la base de datos existiera. Para evitar el conflicto, es que agregamos add-drop-database. Con ésto, nos garantizamos que se agregue la instrucción de dropeo de la base de datos antes de la instrucción de creación de la misma.

Nuestro nuevo dump se ejecutaría asi.

mysqldump --add-drop-database --databases -hhost -uusuario -ppassword basededatos > basededatos.sql

Ahora si, cuando volvamos a ejecutar la restauración, nuestra base de datos debería quedar restaurada sin problema alguno.

A lo mejor te interese leer

• Backup de bases de datos en Mysql
• Simulando show tables y describe de Mysql en PostgreSql
• Update con Subselect en Mysql
• Restaurar un backup plano en PostgreSql
• Cómo crear un trigger con un Definer específico en Mysql

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