Discussion :

[Sve@r]

Bonjour à tous

Je grenouille avec Postgres depuis déjà quelques mois et je commence à bien m'en sortir sur les généralités. J'ai bien compris la façon de gérer les groupes et les login, les clefs primaires, étrangères, les contraintes d'intégrité, les contraintes d'unicité tout ça ça va bien.

Mais là j'ai un problème que je pense simple mais pour l'instant j'arrive pas à le régler via Postgres. J'ai une table de personnes qui contient une colonne nom et une prénom et j'aimerais que mes noms soient toujours en majuscule.
Pour l'instant je gère ça à partir du formulaire de saisie (Qt) où je convertis le nom en majuscule avant de l'insérer mais je me demandais si Postgres ne pouvait pas le faire pour moi. J'ai un peu regardé la doc sur les trigger et les fonctions mais je suis un peu perdu. Il me semble qu'il faudra créer un trigger xxx before insert or update on personne relié à une fonction yyy qui se chargera de convertir le nom mais voilà, question syntaxe je reste un peu dans le flou.

Si qqun pouvait m'aider ce serait sympa. Surtout qu'il existe une fonction upper() en Postgres donc je pense que ça devrait pas trop être difficile.

Merci

[estofilo]

Il me semble qu'il faudra créer un trigger xxx before insert or update on personne relié à une fonction yyy qui se chargera de convertir le nom mais voilà, question syntaxe je reste un peu dans le flou.

Voilà un exemple minimal duquel tu peux partir:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
CREATE FUNCTION maj() RETURNS trigger AS
$$
BEGIN
 new.colonne = upper(new.colonne);
 return NEW;
END
$$ LANGUAGE plpgsql;
 
CREATE TRIGGER montrigger BEFORE UPDATE OR INSERT ON matable 
FOR EACH ROW EXECUTE PROCEDURE maj();

[Sve@r]

Voilà un exemple minimal duquel tu peux partir:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
CREATE FUNCTION maj() RETURNS trigger AS
$$
BEGIN
 new.colonne = upper(new.colonne);
 return NEW;
END
$$ LANGUAGE plpgsql;
 
CREATE TRIGGER montrigger BEFORE UPDATE OR INSERT ON matable 
FOR EACH ROW EXECUTE PROCEDURE maj();

Merci d'avoir répondu. J'ai tapé ton exemple et 1) ça a marché (bon, on va trouver évidemment ça normal) et 2) en y associant pg_admin et pg_dump, ça m'a permis de comprendre qq trucs.

1) le nom de la fonction doit-être unique pour la bdd. Bon, c'est normal.
2) la fonction doit exister avant de créer le trigger qui y fait référence.
3) le nom du trigger est associé à la table dont il fait référence. Donc si j'ai 2 ou 3 tables distinctes qui gèrent chacune un nom, je peux pour toutes ces tables créer un trigger "montrigger" sans créer de conflit

Toutefois il me reste un soucis mineur: la fonction "maj()" est associée à la colonne "colonne". Dans ma bdd, comme ma table "personne" contient la colonne "nom" que je veux convertir en majuscule, j'ai remplacé "new.colonne" par "new.nom" et ça marche nickel.
Mais si jamais je voulais convertir le nom et aussi le prénom, dois-je créer deux fonctions "majNom()" et "majPrenom()" ou bien y a-t-il moyen de créer une fonction plus "universelle" où je lui dis "ici je te passe la colonne personne.nom" ou bien "ici je te passe le colonne personne.prenom" ???

Autre question de détail: pgAdmin3 m'a traduit la fonction en remplaçant "$$" par "$BODY$" (je présume qu'il s'agit de la syntaxe de puriste) et a rajouté en final "LANGUAGE 'plpgsql' VOLATILE COST 100;". C'est le COST 100 qui m'intrigue. La doc parle d'un coût estimé et Postgres cherchera à faire autre chose si le coût réel est plus grand mais là, j'avoue que je suis resté un peu dans le vague...

[estofilo]

Mais si jamais je voulais convertir le nom et aussi le prénom, dois-je créer deux fonctions "majNom()" et "majPrenom()" ou bien y a-t-il moyen de créer une fonction plus "universelle" où je lui dis "ici je te passe la colonne personne.nom" ou bien "ici je te passe le colonne personne.prenom" ???

De même que NEW.nom est modifié dans la fonction, NEW.prenom serait à modifier dans la même fonction, il n'est pas nécessaire d'en créer une autre.

Autre question de détail: pgAdmin3 m'a traduit la fonction en remplaçant "$$" par "$BODY$" (je présume qu'il s'agit de la syntaxe de puriste) et a rajouté en final "LANGUAGE 'plpgsql' VOLATILE COST 100;". C'est le COST 100 qui m'intrigue. La doc parle d'un coût estimé et Postgres cherchera à faire autre chose si le coût réel est plus grand mais là, j'avoue que je suis resté un peu dans le vague...

C'est un renseignement utilisé pour le calcul des plans d'exécution des requêtes. Chaque opération élémentaire a un coût estimé, les fonctions aussi. Quand il y a plusieurs plans d'exécution possibles, l'optimiseur choisit le plus rapide sur la base de ces coûts. En l'occurrence ici, la fonction va être exécutée autant de fois que de lignes insérées ou modifiées, quel que soit le plan d'exécution, donc ce coût n'est pas un facteur de décision.

[Sve@r]

De même que NEW.nom est modifié dans la fonction, NEW.prenom serait à modifier dans la même fonction, il n'est pas nécessaire d'en créer une autre.

Ouaip. Mais c'est pas vraiment "universel". Autant de champs dans ma table => autant de champs dans la fonction. Mais je me doute bien que tout n'est pas parfait.

C'est un renseignement utilisé pour le calcul des plans d'exécution des requêtes. Chaque opération élémentaire a un coût estimé, les fonctions aussi. Quand il y a plusieurs plans d'exécution possibles, l'optimiseur choisit le plus rapide sur la base de ces coûts. En l'occurrence ici, la fonction va être exécutée autant de fois que de lignes insérées ou modifiées, quel que soit le plan d'exécution, donc ce coût n'est pas un facteur de décision.

Sympa. Bon, j'ai compris comment créer une fonction. Et en plus j'ai trouvé une doc Postgres où il y a une fonction d'exemple qui permet d'insérer ou updater une table en une seule requête et ça m'a permis de commencer à tatonner avec ça.

Merci pour tout.