Afin d'améliorer le mécanisme des triggers expliqué dans Chapitre 36, Déclencheurs (triggers), PostgreSQL™ fournit également des triggers sur évènement. À la différence des triggers normaux, qui sont attachés à une seule table et ne capturent que des évènements DML, les triggers sur évènements sont globaux sur une base en particulier et sont capables de capturer tous les évènements DDL.
Comme les triggers normaux, les triggers sur évènement peuvent être écrits dans n'importe quel langage procédural qui inclut le support des triggers sur évènement, ou en C, mais pas en pur SQL.
Un trigger sur évènement se déclenche chaque fois que l'évènement qui lui est associé se déclenche sur la base qui lui est définie. Pour le moment, les seuls évènements supportés sont ddl_command_start, ddl_command_end et sql_drop. Le support pour des évènements additionnels pourrait être ajouté dans des versions ultérieures.
L'évènement ddl_command_start se déclenche juste avant l'exécution d'une commande CREATE, ALTER, ou DROP. Aucune vérification n'est effectuée sur l'existence ou non de l'objet avant de déclencher le trigger sur événement. Attention, cet évènement ne se déclenche pas pour les commandes DDL visant les objets partagés -- bases de données, rôles, et tablespaces -- ou pour les commandes visant les triggers sur évènement eux-même. Le mécanisme de trigger sur évènement ne supporte pas ces types d'objets. ddl_command_start se déclenche également juste avant l'exécution d'une commande SELECT INTO, celle-ci étant l'équivalent de CREATE TABLE AS.
L'évènement ddl_command_end se déclenche juste après l'exécution de ces même ensembles de commandes.
L'évènement sql_drop se déclenche juste avant le trigger sur évènement ddl_command_end pour toute opération qui supprime des objets de la base. Pour lister les objets qui ont été supprimés, utilisez la fontion retournant des ensembles d'objets pg_event_trigger_dropped_objects() depuis le code du trigger sur évènement sql_drop (voir Section 9.28, « Fonctions des triggers sur les événements »). Notez que le trigger est exécuté après que les objets aient été supprimés du catalogue système, il n'est donc plus possible de les examiner.
Les triggers sur évènement (comme les autres fonctions) ne peuvent être exécutés dans une transaction annulée. Ainsi, si une commande DDL échoue avec une erreur, tout trigger ddl_command_end associé ne sera pas exécuté. Inversement, si un trigger ddl_command_start échoue avec une erreur, aucun autre trigger sur évènement ne se déclenchera, et aucune tentative ne sera faite pour exécuter la commande elle-même. De la même façon, si une commande ddl_command_end échoue avec une erreur, les effets de la commande DDL seront annulés, comme elles l'auraient été dans n'importe quel autre cas où la transaction qui la contient est annulée.
Pour une liste complète des commandes supportées par le mécanisme des triggers sur évènement, voir Section 37.2, « Matrice de déclenchement des triggers sur évènement ».
Les triggers sur événement sont créés en utilisant la commande CREATE EVENT TRIGGER(7). Afin de créer un trigger sur évènement, vous devez d'abord créer une fonction avec le type de retour spécial event_trigger. Cette fonction n'a pas besoin (et ne devrait pas) retourner de valeur ; le type de retour sert uniquement comme signal pour que la fonction soit appelée comme un trigger sur évènement.
Si plus d'un trigger sur évènement est défini pour un évènement particulier, ils seront déclenchés par ordre alphabétique de leur nom.
Une définition de trigger peut également spécifier une condition WHEN pour que, par exemple, un trigger ddl_command_start ne soit déclenché que pour des commandes particulières que l'utilisateur souhaite intercepter. Une utilisation typique de tels triggers serait de restreindre la portée des opérations DDL que les utilisateurs peuvent exécuter.
Un exemple complet de trigger