35.1. Aperçu du comportement des déclencheurs

Une fonction déclencheur peut être définie pour s'exécuter avant ou après une commande INSERT, UPDATE ou DELETE, soit une fois par ligne modifiée soit une fois par expression SQL. Si un élément déclencheur se produit, le gestionnaire de déclencheurs est appelé au bon moment pour gérer l'évènement.

La fonction déclencheur doit être définie avant que le déclencheur lui-même puisse être créé. La fonction déclencheur doit être déclarée comme une fonction ne prenant aucun argument et retournant un type trigger. (La fonction déclencheur reçoit ses entrées via une structure TriggerData passée spécifiquement, et pas sous la forme d'arguments de fonctions ordinaires.)

Une fois qu'une fonction déclencheur est créée, le déclencheur (trigger) est établi avec CREATE TRIGGER. La même fonction déclencheur est utilisable par plusieurs déclencheurs.

Les fonctions déclencheurs renvoient une ligne de tableau (valeur de type HeapTuple). Un déclencheur lancé avant une opération a les choix suivants :

• Il peut retourner un pointeur NULL pour sauter l'opération pour la ligne courante (et ainsi la ligne ne sera pas insérée/mise à jour/effacée).

• Pour les seuls déclencheurs INSERT et UPDATE, la valeur de retour devient la ligne qui sera insérée ou remplacera la ligne en cours de mise à jour. Ceci permet à la fonction déclencheur de modifier la ligne en cours d'insertion ou de mise à jour.

Un déclencheur avant, qui n'est pas conçu pour avoir l'un de ces comportements, doit prendre garde à retourner la même ligne que celle qui lui a été passée comme nouvelle ligne (c'est-à-dire, la nouvelle (NEW) ligne pour des déclencheurs INSERT et UPDATE, l'ancienne (OLD) ligne pour les déclencheurs DELETE).

La valeur de retour est ignorée pour les déclencheurs lancés après une opération. Ils pourraient donc très bien renvoyer la valeur NULL.

Si plus d'un déclencheur est défini pour le même événement sur la même relation, les déclencheurs seront lancés dans l'ordre alphabétique de leur nom. Dans le cas de déclencheurs avant, les lignes, susceptibles d'être modifiées, renvoyées par chaque déclencheur deviennent l'argument du prochain déclencheur. Si un des déclencheurs avant renvoie un pointeur NULL, l'opération est abandonnée et les déclencheurs suivants ne sont pas lancés.

Si une fonction déclencheur exécute des commandes SQL, alors ces commandes peuvent relancer des déclencheurs. On appelle ceci un déclencheur en cascade. Il n'y a pas de limitation directe du nombre de niveaux de cascade. Il est possible que les cascades causent un appel récursif du même déclencheur ; par exemple, un déclencheur INSERT pourrait exécuter une commande qui insère une ligne supplémentaire dans la même table, entraînant un nouveau lancement du déclencheur INSERT. Il est de la responsabilité du programmeur d'éviter les récursions infinies dans de tels scénarios.

Quand un déclencheur est défini, des arguments peuvent être spécifiés pour lui. L'objectif de l'inclusion d'arguments dans la définition du déclencheur est de permettre à différents déclencheurs ayant des exigences similaires d'appeler la même fonction. Par exemple, il pourrait y avoir une fonction déclencheur généralisée qui prend comme arguments deux noms de colonnes et place l'utilisateur courant dans l'une et un horodatage dans l'autre. Correctement écrit, cette fonction déclencheur serait indépendante de la table particulière sur laquelle il se déclenche. Ainsi, la même fonction pourrait être utilisée pour des événements INSERT sur n'importe quelle table ayant des colonnes adéquates, pour automatiquement suivre les créations d'enregistrements dans une table de transactions par exemple. Elle pourrait aussi être utilisée pour suivre les dernières mises à jours si définie comme un déclencheur UPDATE.