Le portail francophone de la géomatique

Bonjour,
Je ne suis pas non plus un as des triggers et ignore si la fonction update peut être utilisée de la sorte mais si tel est le cas, je me demande si les champs affublés de new ne devraient pas plutôt être à gauche de égal ( soit

Begin
update  urba.n_zone_urba_76010_076
set (new.idurba,new.liblong, new.typezone, new.destdomi, new.insee, new.datappro, new.datvalid)=(idurba, liblong, typezone, destdomi, insee, datappro,datvalid)
from t2c where new.libelle=t2c.libelle;
return new;
End;

En fait, quand vous utilisez un trigger insert for each row, Postgresql attribue l'appellation new à la nouvelle entité qui est en cours de création; n_zone_urba_76010_076 devient donc ici new . http://docs.postgresql.fr/9.2/plpgsql-trigger.html C'est donc cette valeur que vous essayez de mettre à jour d'où le fait qu'il doit être du côté du SET. Ce pour quoi postgresql estime qu'il y a une ambiguité sur le champ new.idurba.
En outre, je n'ai pas compris pourquoi vous ne sélectionnez pas directement depuis la table t2c mais faites une sélection préalable des mêmes champs. J'ai donc enlevé cette partie.
PS: je ne pense même pas que l'option new soit obligatoire dans la fonction vu que la mise à jour se fait par défaut sur la ligne en entrée, mais bon...

Bonjour,
Non, a priori, ce n'est pas normal ou en tout cas, ce n'est pas ce qu'on en attend !!! Donc, il y a des trucs à revoir
il n'y a pas d'autre trigger en exécution sur cette table? Votre trigger, il est bien défini before insert et for each row?

Le second aussi se met à jour ou est-ce juste le premier qui est mis à jour? Et si vous ajoutez plus d'objets, comment ça réagit?

Et si vous mainteniez le new dans la requête pour voir?

Bonsoir, Merci à SANTANNA et JP LLORENS pour votre précieuse aide, le trigger marche à merveille et la mise à jour se fait automatiquement après le remplacement de BEFORE par AFTER dans le trigger.
Encore merci beaucoup et très bonne soirée.

Bonjour,

Oui c'est exactement ca: pour la mise à jour d'une autre table depuis un trigger sur une table, il faut que la table en question ait ete mise à jour avant qu'on puisse propager le changement.

Un trigger peut être défini au niveau du statement (la requête elle-meme, trigger appelé une seule fois pour la requête) ou au niveau de la ligne (trigger appelé pour chaque ligne concernée par la requete)
Il peut ensuite être défini comme BEFORE ou AFTER.

Pour les trigger agissant sur une ligne (ROW LEVEL trigger), comme c'est le cas ici, la doc donne une règle générale:

• Si le trigger doit modifier une valeur de la table sur laquelle il est défini, alors le trigger doit être déclaré comme BEFORE: c'est à dire agissant avant que la ligne ne soit écrite en base, ce qui permet donc de modifier les valeurs de la ligne.

• Si le trigger doit modifier la valeur d'une autre table, alors il doit être défini comme AFTER: la ligne de la table déclenchant le trigger doit être écrite, traitée par le système, pour que sa valeur soit prise en compte dans les autres tables.
Un AFTER trigger ne peut plus modifier les valeurs de la ligne: celle-ci est déjà écrite en base.

Ces deux "états" d'un trigger conditionnent la visibilité des données à l'intérieur de la fonction du trigger:
Dans une table vide dans laquelle on insère un record, un BEFORE trigger voit la table vide (si on fait un count(*) de la table dans le trigger) et un AFTER trigger voit la table avec un record dedans.
Le BEFORE peut, en revanche, agir sur la donnée à insérer dans la table (en changeant la valeur, en affectant une autre valeur à une colonne, etc.) tandis que le AFTER ne peut plus agir sur la table, mais peut par contre propager la valeur de la ligne à d'autres tables (pour faire un insert ou un update dans une autre table, comme c'est le cas dans ce thread).

Bouh, je sais pas si je suis très clair
La doc décrit tout ca en détail (http://www.postgresql.org/docs/9.2/stat … ition.html)

Nicolas