PostgreSQLno tiene un modelo de manejo inteligente de excepciones. En cualquier momento que el reconocedor sintáctico, el planeador, el optimizador o el ejecutor deciden que una aserción no puede ser procesada, la transacción completa se aborta y el sistema regresa al estado de espera de consultas por parte del cliente.
Sin embargo, es posible engancharse al mecanismo de manejo de errores para notar cuando ocurre esto. Pero actualmente es imposible decir qué fue lo que realmente causó el aborto de la operación (error de conversión en la entrada o la salida, error de punto flotante, error del reconocedor sintáctico, etc.). Es también posible que el DBMS se encuentre en un estado inconsistente en este punto, de tal manera que regresar al ejecutor o ingresar otros comandos puede corromper severamente la base de datos. De tal forma que si luego de informar al cliente que la transacción fué abortada, lo más sensato es no continuar con la operación.
De esta forma, lo único que PL/pgSQL hace actualmente cuando se encuentra ante un aborto de operación durante la ejecución de un trigger, es escribir en la bitácora alguna información describiendo el número de línea y el tipo de aserción que estaba siendo ejecutada.
Un detalle a tomar en cuenta es que al escribir las funciones en
PL/pgSQL es el manejo de los apóstrofes. El texto de las funciones
dentro de CREATE FUNCTION va entre apóstrofes, así que
si estos ocurren dentro del cuerpo de la función deberán ir dobles o
escapados con una diagonal: '' o \'.