Bien que la très grande majorité des triggers implique des fonctions triggers écrites par les utilisateurs, PostgreSQL fournit quelques fonctions triggers natives, pouvant être utilisées directement dans des triggers définis par un utilisateur. Elles sont résumées dans Tableau 9.97. (Des fonctions triggers natives supplémentaires existent pour implémenter des contraintes de clés étrangères et des contraintes d'index différés. Ce ne sont pas celles documentées ici car les utilisateurs ne les utilisent pas directement.)
Pour plus d'informations sur la création de triggers, voir CREATE TRIGGER.
Tableau 9.97. Fonctions triggers natives
Fonction Description Exemple d'utilisation |
---|
Supprime les opérations de mise à jour à vide. Voir ci-dessous pour les détails.
|
Met à jour automatiquement une colonne
|
Met à jour automatiquement une colonne
|
La fonction suppress_redundant_updates_trigger
, quand
appliqué sur un trigger BEFORE UPDATE
niveau ligne,
empêchera toute mise à jour qui ne change pas réellement les données dans
la ligne. Ceci surcharge le comportement habituel qui est de toujours
réaliser une mise à jour physique de la ligne, que les données changent ou
pas. (Ce comportement habituel rend les mises à jour plus rapides vu qu'il
n'est pas besoin de vérifier, et est aussi plus utile dans certains cas.)
Idéalement, vous devriez éviter d'exécuter des mises à jour qui ne
changent pas vraiment les données de l'enregistrement. Des mises à jour
redondantes peuvent prendre un temps considérable, tout spécialement si
beaucoup d'index sont à mettre à jour, et l'espace des lignes mortes sera
à nettoyer plus tard. Cependant, détecter ce genre de cas dans le code
client n'est pas toujours simple, voire possible, et écrire des
expressions pour les détecter peut être source d'erreurs. Une alternative
revient à utiliser
suppress_redundant_updates_trigger
, qui ignorera les
mises à jour qui ne modifient pas les données. Vous devez faire attention
en l'utilisant. Le trigger prend un peu de temps pour chaque
enregistrement, donc si la majorité des enregistrements affectés par les
mises à jour fait un changement, l'utilisation de ce trigger rendra les
mises à jour plus lentes en moyenne.
La fonction suppress_redundant_updates_trigger
peut
être ajoutée ainsi à une table :
CREATE TRIGGER z_min_update BEFORE UPDATE ON tablename FOR EACH ROW EXECUTE FUNCTION suppress_redundant_updates_trigger();
Dans la plupart des cas, vous avez besoin d'exécuter ce trigger à la fin pour chaque ligne, pour qu'il n'écrase pas l'exécution d'autres triggers qui voudraient modifier la ligne. Gardez en tête que les triggers sont exécutés dans l'ordre alphabétique de leur nom, vous devez de ce fait choisir un nom de trigger qui le fait arriver en dernier parmi les triggers de cette table. (D'où le préfixe « z » dans l'exemple.)