QGIS » ASGARD

Avez-vous bien exécuté dans l'éditeur sql courant ? :
SET ROLE g_admin ;

lorsque je lance la commande GRANT g_pect TO g_admin à partir de geobase_snum de mon localhost et non de geobase_snum de ma connection etienne.lousteau celà marche - j'ai fait ainsi pour tous les paragraphes suivants, avec succés - jfp

j'avais aussi fait avec succés SET ROLE g_admin à partir de ma connection etienne.lousteneau

Je n'arrive pas à reproduire le problème. Est-ce que vous pourriez (re)lancer les requêtes suivantes sur la connexion etienne.lousteau et m'indiquer le résultat :

1. à titre de contrôle :
SET ROLE g_admin ;
GRANT g_pect TO g_admin ;

2.
SELECT rolcreaterole FROM pg_roles WHERE rolname = 'g_admin' ;

pour la première commande : NOTICE: le rôle « g_admin » est déjà un membre du rôle « g_pect » GRANT ROLE Requête exécutée avec succès en 56 msec. - en effet, je l'avais créée sans problème entre temps sans passer par la connection etienne.lousteau mais en la lançant à partir de la base geobase_snum de mon localhost

pour la deuxième commande : rolecreaterole boolean true

j'oubliais ce détail.

Dans ce cas, pourriez-vous plutôt tester (toujours sur la connexion etienne.lousteau) :
SET ROLE g_admin ;
REVOKE g_pect FROM g_admin ;

puis, si ça a marché, relancer :
GRANT g_pect TO g_admin ; ?

la première commande a marché

la deuxième a aussi marché avec le message GRANT ROLE

Merci beaucoup pour votre patience !

Tout semble donc en ordre du côté de l'extension, mais ça ne nous dit pas ce qui s'est passé lors de votre essai de ce matin... Est-ce que vous aviez bien lancé toutes les requêtes de cette partie à la suite, sans changer de fenêtre de requête ?

Très concrètement, la commande CREATE ROLE g_pect ; et la commande GRANT g_pect TO g_admin ; requièrent toutes les deux exactement la même chose : être lancées par un rôle avec l'attribut CREATEROLE (la deuxième peut aussi être lancée par un membre de g_pect avec option ADMIN, comme le suggère le message d'erreur, mais ce n'est pas le cas ici). g_admin a CREATEROLE, mais cet attribut n'est pas automatiquement héritable - c'est la raison pour laquelle etienne.lousteau doit endosser g_admin avec un SET ROLE g_admin avant d'exécuter les commandes.

Si vous avez lancé toutes les requêtes à la suite dans un même onglet de l'éditeur de requêtes (et sans faire de (RE)SET ROLE au milieu), alors je ne vois pas ce qui a pu se passer.

SET ROLE g_admin ;
CREATE ROLE g_pect ;
COMMENT ON ROLE g_pect IS 'Membres du Pôle Étude et Connaissances Territoriales' ;
GRANT g_pect TO g_admin ;

Nous allons attendre de voir si d'autres sont confrontés au même problème.

Quant à la connexion... L'objectif était de se reconnecter à la base avec un autre rôle que le super-utilisateur. Est-ce que vous voyez une autre façon de le faire ?

effectivement, le mieux est d'attendre pour voir si d'autres testeurs sont confrontés au même problème - quand à la connexion, vous avez raison - je suis surtout habitué à créer mes connexions via qgis et non via pgadmin(IV)

Comme tout le monde. Comme dans pgAdmin il n'est pas nécessaire de créer une connexion par base, on en configure généralement une lorsque le serveur est installé (au pire une pour le super-utilisateur si elle n'existe pas déjà et une pour un rôle de connexion individuel lambda) et on ne revient jamais dessus. Alors que dans QGIS, comme on doit le refaire à chaque nouvelle base...