Discussion :

[Quentin]

Bonjour à tous,

Je rencontre quelques problèmes pour savoir si PostgreSQL est capable de gérer des événéments dépassant le cadre des trigger. Par exemple, lors du démarrage ou l'arrêt de la base, lors d'une authentification utilisateur (échouée ou non)...

Certains SGBD implémentent une commande permettant ce type de gestion (CREATE EVENT pour Sybase ASA, CREATE EVENT MONITOR pour DB2), mais sous PostgreSQL, je n'ai rien pu trouver d'équivalent dans la documentation en ligne. J'imagine que cette commande ne fait pas partie du standard SQL.

Bref, est-ce qu'il existe une fonctionnalité de ce type pour PostgreSQL ?

Merci d'avance

[kryskool]

Je rencontre quelques problèmes pour savoir si PostgreSQL est capable de gérer des événéments dépassant le cadre des trigger. Par exemple, lors du démarrage ou l'arrêt de la base, lors d'une authentification utilisateur (échouée ou non)...

Tu trouveras comment écrire dans le fichier de log de postgresql dans la documentation de PG.

pour l'identification des personnes tu peut utiliser une procedure stockée qui ira également ecrire dans ce fichier.

[Quentin]

Merci pour ta réponse, kryskool.

En ce qui concerne l'authentification client, tout traiter à partir d'une procédure stockée est effectivement une solution simple.

Par contre, je ne vois pas le rapport entre l'instruction RAISE de PL/pgSQL et la gestion d'événements propres à la base
Pourrais-tu me donner plus de détail ?

[kryskool]

Par contre, je ne vois pas le rapport entre l'instruction RAISE de PL/pgSQL et la gestion d'événements propres à la base
Pourrais-tu me donner plus de détail ?

L'instruction RAISE te permet de logguer des messages dans postgres.log donc tracer des évènements qui se sont passés sur la base

[Quentin]

L'instruction RAISE te permet de logguer des messages dans postgres.log donc tracer des évènements qui se sont passés sur la base

Jusque là, d'accord, j'avais bien suivi Mais comment faire pour les attraper ces événements ?

[kryskool]

Jusque là, d'accord, j'avais bien suivi mais comment faire pour les attraper ces événements ?

Tous dépend si tu en as besoin sur l'instant ou si cela te sert a faire un rapport d'erreur en fin de journée

KrysKool

[Quentin]

Dans mon cas, j'en ai besoin à l'instant où l'événement se produit.

En tout cas, je te remercie pour ta patience et tes réponses

[kryskool]

donc dans ce cas la, le RAISE ne te sera d'aucune utilité. Tu as le choix :
- un trigger positionné sur la table a surveiller
- ou jouer avec la méthode LISTEN que j'avais oublié de te parler

[Quentin]

Comment je le disais au début, ces "event" que je souhaite gérer ne sont pas associés à une table mais à la base elle-même, d'où l'impossibilité de passer par trigger. Pour te donner un exemple, ce serait purger une table de manoeuvre au moment d'arrêter le moteur de la base

Par contre, le couple LISTEN-NOTIFY est intéressant, je vais me pencher dessus. Il ne résoudra peut-être pas le problème initial de la façon que j'imaginais, mais comme solution de contournement, ça ira sûrement.

Encore merci pour toutes tes réponses.