Gestion d'événements hors tables [Résolu]

Quentin · 10/02/2005, 11h47

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 · 10/02/2005, 12h20

Citation:

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 · 10/02/2005, 16h29

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 · 10/02/2005, 17h15

Citation:

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 · 10/02/2005, 17h57

Citation:

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 · 10/02/2005, 19h34

Citation:

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 · 10/02/2005, 19h57

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 · 10/02/2005, 20h53

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 · 11/02/2005, 00h09

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.

10/02/2005, 11h47	#1
Quentin Membre habitué Inscription : mai 2002 Messages : 131 Détails du profil Informations forums : Inscription : mai 2002 Messages : 131 Points : 142 Points : 142	Gestion d'événements hors tables 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
	00

10/02/2005, 16h29	#3
Quentin Membre habitué Inscription : mai 2002 Messages : 131 Détails du profil Informations forums : Inscription : mai 2002 Messages : 131 Points : 142 Points : 142	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 ?
	00

10/02/2005, 19h57	#7
Quentin Membre habitué Inscription : mai 2002 Messages : 131 Détails du profil Informations forums : Inscription : mai 2002 Messages : 131 Points : 142 Points : 142	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
	00

10/02/2005, 20h53	#8
kryskool Membre éclairé Inscription : janvier 2005 Messages : 336 Détails du profil Informations personnelles : Âge : 34 Informations forums : Inscription : janvier 2005 Messages : 336 Points : 353 Points : 353	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
	00

11/02/2005, 00h09	#9
Quentin Membre habitué Inscription : mai 2002 Messages : 131 Détails du profil Informations forums : Inscription : mai 2002 Messages : 131 Points : 142 Points : 142	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.
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email