Retorno de funciones de Trigger ejecutadas antes de operaciones DELETE en PostgreSQL

Al ejecutar una función de trigger antes de operaciones DELETE no debe olvidarse el retorno de la función.

RETURN NULL hace que se salte la ejecución de la operación por lo que no se realizará el borrado de los registros. De modo que si queremos que efectivamente se realice la operación DELETE el retorno debe ser algo diferente de NULL.

Consideraciones al renombrar una tabla en PostgreSQL

Renombrar una tabla es algo sencillo, simplemente hacemos uso del comando ALTER TABLE:

ALTER TABLE nombre_actual RENAME TO nuevo_nombre;

Sin embargo, este comando sólo renombra la tabla mientras los nombres de sus índices, secuencias, llaves foráneas y otros constraints permanecen iguales. Esto podría no ser un problema, pero si estos nombres son parte del diseño de la BD y queremos cambiarlos, deberemos renombrar los índices y secuencias uno por uno:

Evitar errores en búsquedas sobre campos de texto con mayúsculas y minúsculas en PostgreSQL

Si los campos de texto se almacenan con mezclas de mayúsculas y minúsculas, las búsquedas se ven afectadas y podrían no entregar los resultados que esperamos. Para ilustrarlo supongamos que tenemos una tabla llamada 'persona' con un campo 'nombre', en el que almacenaremos la información introducida por un usuario mediante un formulario y que no procesaremos dicho campo, por lo que el usuario podrá ingresar el texto usando mayúsculas y minúsculas. Luego de varios ingresos tendremos los siguientes datos:

Error al cargar backup de PostgreSQL 9.1 a 8.4 con funciones que usen PL/pgsql

Al querer cargar un archivo de backup desde una versión más reciente a una anterior siempre surgen problemas. Este es uno de ellos si cargamos un archivo de backup hecho con pg_dump desde la versión 9.1 a una versión anterior y tenemos funciones (tal vez triggers) programados con PL/pgsql. A mí me sucede porque mi máquina de trabajo tiene un Fedora 17 y mi servidor tiene Debian 6. Al intentarlo aparecerá el siguiente error:

ERROR: error de sintaxis en o cerca de «EXTENSION»
LÍNEA 1: CREATE EXTENSION IF NOT EXISTS plpgsql WITH SCHEMA pg_catalo...

Y no creará las funciones que dependan de este lenguaje.

Porqué usar llaves primarias autoincrementables

En un post anterior explicaba una ventaja de los campos autoincrementables, pero además de ésta existen otras razones que hacen que sea una buena práctica incluir un campo autoincrementable como llave primaria (PK) en cada tabla.

Incluir campos autoincrementables como llaves primarias en cada tabla de una base de datos tiene varias ventajas, que hacen que usarlas sea una buena práctica. Veamos algunas de esas buenas razones:

1. Facilita la obtención del último registro insertado.
   

Obtener el último registro insertado en una tabla en PostgreSQL

Podría parecer algo muy sencillo pero la verdad es que a veces puede no serlo tanto, sobretodo si no tuvimos en cuenta esto en el diseño de la BD. Según la tabla podemos encontrarnos con 2 posibilidades:

• Tablas sin campo único autoincrementable
• Tablas con campo único autoincrementable

Veamos cada una en detalle:

Construir SQL dinámicos en PostgreSQL con PL/pgSQL

A veces queremos ejecutar un SQL dentro de una función (como en un trigger) en el que los nombres de los campos o de la tabla a consultar varian, es decir que es dinámico.

Si estamos usando el lenguaje procedimental de PostgreSQL (PL/pgSQL), esto puede hacerse a través de concatenación de cadenas de texto.

Para el ejemplo, supongamos que queremos una función que nos genere el código siguiente para un campo y tenemos la misma estructura para diferentes tablas, así que queremos que la función sea reutilizable. El código es muy sencillo: tomar el último valor para el campo, sumarle 1 y devolver el resultado:

Uso de LIKE con campos de tipo numérico en PostgreSQL

El operador LIKE de SQL sirve para comparar expresiones según un patrón (más info acá). Pero funciona sólo con campos tipo texto (CHAR, VARCHAR, TEXT). Si se quiere hacer una comparación sobre un campo tipo INTEGER no va a funcionar (tuve que hacer dicha comparación al configurar un campo de formulario con autocompletado con Symfony).

Sin embargo se puede hacer y el truco es muy sencillo, ya que simplemente debemos 'convertir' el campo de tipo entero a una cadena de texto. Esto se hace con la función TO_CHAR. Veamos un ejemplo de consulta sencilla con esta función:

División entre enteros en PL/pgSQL

La división entre enteros elimina automáticamente la parte decimal del resultado. Esto puede ser contraproducente si necesitamos cálculos que hagan uso de la parte decimal, incluso si simplemente queremos redondear y obtener un entero, ya que obtendremos un resultado erróneo cuando la parte decimal sea mayor a 0.5. Consideremos por ejemplo que vamos a almacenar el valor del salario mensual de un contrato y queremos calcular el valor del día como valor entero y guardarlo para posteriores operaciones:

DECLARE
  ...
BEGIN
  ...
  NEW.salario_base_diario := NEW.salario_base_mensual / 30;