From: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
---|---|
To: | alain(dot)benard(at)nancy(dot)inra(dot)fr |
Cc: | pgsql-fr-generale(at)postgresql(dot)org |
Subject: | Re: Délégation de droits par une procédure stockée - CREATE ROLE en plpgsql. |
Date: | 2012-02-09 10:31:24 |
Message-ID: | 87ipjgcn7n.fsf@hi-media-techno.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-fr-generale |
Alain Benard <alain(dot)benard(at)nancy(dot)inra(dot)fr> writes:
> 2. second scénario : j'essaie de créer une procédure stockée qui
> s'exécute avec les droits du definer (un admin par exemple) et qui
> crée le compte utilisateur en l'ajoutant dans un groupe fixé à
> l'avance. Par exemple une fonction ajout_lecteur(nomlecteur) qui
> crée le rôle nomlecteur et l'inscrit dans le groupe habilité à
Cette approche me parait bonne, c'est celle que j'aurais privilégié
également. Une subtilité nous échappe donc.
> consulter la base en question. En dehors du contexte d'exécution de
> la procédure stockée le compte n'existe pas, c'est à dire qu'il n'y
> a pas persistance de la création du compte : pour affirmer ça j'ai
Je suis étonné. Est-ce que la transaction qui invoque la fonction est
bien terminée avec un COMMIT et sans code d'erreur ?
> req varchar(4000);
Préférer text.
> EXCEPTION
> WHEN OTHERS THEN
Pour les tests, ne pas traiter les erreurs du tout, pour la production,
ne pas cacher les problème sous le tapis si le code de gestion des
erreurs ne sait pas quoi en faire, ce qui semblerait bien être le cas
ici.
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2012-02-09 10:32:07 | Re: Délégation de droits par une procédure stockée - CREATE ROLE en plpgsql. - Problème réglé |
Previous Message | Alain Benard | 2012-02-09 10:24:48 | Re: Délégation de droits par une procédure stockée - CREATE ROLE en plpgsql. - Problème réglé |