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, table_rewrite 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, DROP, SECURITY LABEL, COMMENT, GRANT ou REVOKE. 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. Pour obtenir plus de détails sur les opérations DDL qui interviennent, utilisez la fonction renvoyant un ensemble de lignes pg_event_trigger_ddl_commands() à partir du code du trigger répondant à l'événement ddl_command_end (voir Section 9.29). Notez que le trigger est exécuté après les actions qui sont intervenues (mais avant les validations de transactions), aussi les catalogues systèmes qui peuvent être lus ont déjà été modifiés.

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 fonction retournant des ensembles d'objets pg_event_trigger_dropped_objects() depuis le code du trigger sur événement sql_drop (voir Section 9.29). 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.

L'événement table_rewrite se déclenche juste avant qu'une table soit modifiée par certaines actions des commandes ALTER TABLE et ALTER TYPE. Il existe d'autres commandes qui permettent de modifier une table, tel que CLUSTER et VACUUM, mais l'événement table_rewrite n'est pas déclenché pour eux. Pour trouver l'OID de la table qui a été réécrite, utilisez la fonction pg_event_trigger_table_rewrite_oid() (voir Section 9.29). Pour trouver la raison de la réécriture, utilisez la fonction pg_event_trigger_table_rewrite_reason().

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 40.2.

Les triggers sur événement sont créés en utilisant la commande CREATE EVENT TRIGGER. 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.