Vous n'êtes pas identifié(e).
Pages : 1
Bonjour à tous,
J'ai résolu il y a qq jours un bug lié à l'existence d'un trigger sur une table détruite.
Question 1) Je poste ce sujet rapidement sans avoir encore bien analyé l'origine du problème cedi dit, tel que décrit ci-dessus, cela m'a étonné et je cherche un outil qui pourrait prévenir l'existence d'un tel bug ou autre?
Question 2) Je viens de tester SchemaSpy qui possède une "section Anomalies" mais sauf erreur de ma part les triggers et fonctions ne sont pas (encore) traitées pour PostgreSQL. Avez-vous une autre info?
Merci d'avance.
Hors ligne
Sans plus de détails sur votre problème, je vois mal comment vous aider. Les triggers ont une dépendance sur la table associée, il n'est donc pas possible de supprimer la table sans supprimer les triggers associés.
Julien.
https://rjuju.github.io/
Hors ligne
Bien sûr que les triggers associés à une table sont liés à cette table et donc détruits si l'on détruit la table.
Ceci dit, et c'était le bug, il peut y avoir un trigger sur une autre table qui intéragit avec une table tiers. C'est du code sans aucun lien et donc la destrcution de la table tiers est possible simplement, l'erreur ne se produira qu'à l'éxécution.
Je n'ai pas trouvé d'outil qui vérifie ou aide à l'analyse de ce cas de figure et je ne ferme donc pas le sujet, un lecteur futur aura peut-être une piste.
En ce qui me concerne je vais 'simplement' écrire un petit script qui vérifiera que les tables utilisées dans mes fonctions exsitent toujours.
Hors ligne
Ce serait un bug si c'était une fonctionnalité indiquée dans la documentation. Mais la documentation n'en fait pas part. Elle indique même clairement que, pour le serveur PostgreSQL, ce qui se passe dans une procédure stockée lui est totalement inconnue. Il ne peut donc pas être au courant d'un lien entre le travail d'une procédure stockée et les objets de la base.
À ma connaissance, il n'existe pas d'outils le faisant et il sera assez difficile d'en créer un qui ne détectera pas de faux positifs. Le mieux est donc en effet d'écrire le sien, tout en sachant qu'il y a de fortes chances de faux positifs.
Guillaume.
Hors ligne
Ah, forcément avec plus de détail on comprend mieux.
Vous pouvez regarder du côté de https://github.com/okbob/plpgsql_check.
Julien.
https://rjuju.github.io/
Hors ligne
Hello les admin,
Je tavaille avec PostgreSQL depuis 1999, sans parler de mes contacts avec Ingres dans les annés 80, jamais je n'ai parlé de bug PostgreSQL, relisez bien mon post.
Vous répondez à mes questions à partir de "A ma connaissance ..." , merci pour cela et voici mes commentaires.
- cela générera des faux posififs : Oui* (sauf à intrduiduire des règles de codage) ce qui n'est pas un problème car mon soucis est la robustesse (absence de bug).
*idem principe de la page Anomalies de SchemaSpy
- je vais regarder plpgsql_check avant d'écrire mon scirpt, il est peut-être oppurtun de proposer une fonctionnalité complémentaire à ce projet
Dernière modification par PmGs7 (04/09/2018 08:22:23)
Hors ligne
Vous pouvez regarder du côté de https://github.com/okbob/plpgsql_check.
Super, c'est exactement ce que je cherchais.
MERCI
Dernière modification par PmGs7 (07/09/2018 00:30:49)
Hors ligne
Pages : 1
