Triggers

• Définition
  • Bloc PL/pgSQL exécuté automatiquement en réponse à certains événements sur une table (INSERT, UPDATE, DELETE).
• Motivation
  • Assurer l'intégrité des données, automatiser des tâches, appliquer des contraintes complexes non gérables uniquement par SQL.
• Exemples
  • Utiliser des triggers pour enregistrer l'historique des modifications ou valider des conditions spécifiques avant les mises à jour.
• Syntaxe générale
  • Structure de base pour créer un trigger dans PL/pgSQL.

Qu'est-ce que c'est ?

« Déclencheur » = bloc PL/pgSQL exécuté automatiquement en réponse à un événement sur une table ou une vue.

• Associé à une table ou une vue spécifique
• S'exécute lors d'un ordre DML (INSERT, UPDATE, DELETE) sur cette table
• Types de triggers :
  • BEFORE trigger : s'exécute avant l'action DML, permet de valider ou modifier les données.
  • AFTER trigger : s'exécute après l'action DML, souvent utilisé pour enregistrer des logs ou des effets dérivés.

À quoi ça sert ?

• Vérifier des contraintes non exprimables en SQL (exemple : validation de relations hiérarchiques comme les ancêtres dans une arborescence)
• « Tenir un journal » pour certaines mises à jour :
  • Par exemple, lorsqu'une mise à jour se produit dans une table, un trigger peut enregistrer l'événement dans une autre table pour garder une trace des modifications.
• Automatiser des calculs ou mises à jour complexes :
  • Exemple : recalculer automatiquement un total ou une moyenne dans une table parent après une mise à jour dans une table enfant.

Exemple 1

Créer un trigger qui prévienne d'une suppression dans la table client :

CREATE OR REPLACE FUNCTION log_suppression_client()
RETURNS trigger AS $$
BEGIN
    RAISE NOTICE 'Suppression d''un client.';
    RETURN OLD;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER avant_supp_cli
BEFORE DELETE ON client
FOR EACH ROW
EXECUTE FUNCTION log_suppression_client();

Explication : Ce trigger avant_supp_cli est un trigger "BEFORE DELETE" qui s'exécute avant chaque suppression dans la table client. Il affiche un message de notification dans la console serveur.

Exemple 2

Créer un trigger qui agit en cas de baisse du prix :

CREATE OR REPLACE FUNCTION log_baisse_prix()
RETURNS trigger AS $$
BEGIN
    IF OLD.prixht IS NOT NULL AND NEW.prixht IS NOT NULL AND OLD.prixht > NEW.prixht THEN
        RAISE NOTICE 'Ancien prix : %', OLD.prixht;
    END IF;
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER post_maj_prix
AFTER UPDATE ON article
FOR EACH ROW
EXECUTE FUNCTION log_baisse_prix();

Explication : Ce trigger s’exécute après chaque mise à jour de article ; il vérifie si le prix baisse et affiche un message serveur avec RAISE NOTICE.

Syntaxe

CREATE OR REPLACE FUNCTION fonction_trigger()
RETURNS trigger AS $$
BEGIN
    -- Corps du trigger
    RETURN NEW; -- ou RETURN OLD selon le cas
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER nom_trigger
{ BEFORE | AFTER | INSTEAD OF }
{ INSERT | UPDATE | DELETE | TRUNCATE | ... }
ON nom_table
[ FOR EACH ROW ]
EXECUTE FUNCTION fonction_trigger();

• BEFORE/AFTER : moment d’exécution.
• FOR EACH ROW : une fois par ligne modifiée.
• Les triggers s’appuient toujours sur une fonction PL/pgSQL retournant trigger.

Valeurs à retourner dans une fonction de trigger

Règle synthétique : les triggers BEFORE utilisent la valeur renvoyée pour exécuter ou non la modification. Les triggers AFTER ignorent le retour, mais PostgreSQL exige tout de même qu’une valeur (OLD ou NEW) soit retournée.

Gestion des erreurs

• PL/pgSQL offre un mécanisme de gestion d’erreurs avec des blocs EXCEPTION.
• Deux niveaux :
  • Programmation : capturer et traiter les exceptions dans les fonctions ou triggers.
  • Base de données : erreurs SQL (contrainte, syntaxe, accès interdit…).

Objectif : rendre les fonctions robustes et contrôler précisément les erreurs de manipulation de données.

Lever une erreur dans PL/pgSQL

• Une fonction ou un trigger peut interrompre l’exécution avec RAISE EXCEPTION.
• Permet de signaler qu’une condition métier n’est pas respectée.
• Le message et le code peuvent être personnalisés :

  IF NEW.stock < 0 THEN
      RAISE EXCEPTION 'Stock négatif interdit (id=%)', NEW.id;
  END IF;

• L’exception annule la commande qui a déclenché le trigger.

Erreurs BD : intuition

• Exemple 1 : SELECT * FROM cliant;
  • ERROR: relation "cliant" does not exist — faute de nom de table.
• Exemple 2 : contrainte unique non respectée
  • ERROR: duplicate key value violates unique constraint
  • L’insertion ou la mise à jour échoue si une clé existe déjà.

Identifier les messages d’erreur permet de diagnostiquer et sécuriser les opérations en base PostgreSQL.

Levée d’erreur personnalisée

• RAISE EXCEPTION : permet de lever une erreur avec un message explicite.
  • RAISE EXCEPTION 'Message d''erreur (%)', variable;
  • On peut préciser un SQLSTATE personnalisé si nécessaire :

  RAISE EXCEPTION USING
      MESSAGE = 'Stock insuffisant',
      ERRCODE = 'P0001';

• Interrompt la transaction en cours, comme une contrainte violée.
• Permet de définir des messages clairs pour les cas métiers particuliers.

Utilité : renforcer la lisibilité et la robustesse des règles métier directement en base PostgreSQL.

Application : contraintes non exprimables en SQL

• Certaines règles métier ne peuvent pas être exprimées par des contraintes SQL classiques.
• Objectif : les détecter et les bloquer avec un trigger PL/pgSQL.
• Étapes :
  • Détection : identifier les cas invalides dans le trigger.
  • Refus : lever une erreur (RAISE EXCEPTION).
  • Signalement : message explicite pour l’utilisateur ou le développeur.
• Exemples : relations cycliques interdites, stock négatif, validation de hiérarchies incohérentes.