ASGARD

Importer une table de données ne présente aucune difficulté particulière, que ce soit avec le gestionnaire de bases de données de QGIS, le terminal interactif psql, pg_restore ou encore l’utilitaire GDAL ogr2ogr. Il en va de même pour tout objet qui ne soit pas un schéma.

Si toutefois le script exécuté lors de l’import contient des commandes de création de schémas, il devient nécessaire de prendre en considération la règle d’ASGARD qui exclut que le producteur^[1] d’un schéma puisse être un rôle de connexion^[2], sauf s’il s’agit d’un super-utilisateur^[3].

Dans ce cas, en l’absence de précaution, l’import risque d’échouer avec un message de la forme suivante :

ERREUR: ECS0 > TA0 > TA3. Opération interdite (schéma c_bibliotheque). Le producteur/propriétaire du schéma ne doit pas être un rôle de connexion.

ERREUR: ECS0 > TA0 > TA3. Opération interdite (schéma c_bibliotheque). Le producteur/propriétaire du schéma ne doit pas être un rôle de connexion.

La suite de cette partie explique comment, selon l'outil choisi pour l'import, on pourra procéder pour définir un producteur qui soit un rôle de groupe^[4].

Une fois cette question résolue, l'import d'un schéma diffère peu de la création par une commande SQL, une fonctionnalité de pgAdmin ou toute autre méthode :

• le schéma sera référencé^[5] dans la table de gestion^[6] s'il ne l'était pas déjà (cas, par exemple, de la restauration d'un schéma). À noter que, dans tous les cas, le producteur du schéma sera le rôle désigné comme tel lors de l'import et non celui qui aurait pu être préalablement renseigné dans la table de gestion ;

• sans considération des informations contenues dans le script d'import quant aux propriétaires des objets, le producteur du schéma sera fait producteur de tous les objets créés dans le schéma lors de l'import ;

• si le script d'import contient des commandes d'attribution ou de révocation de droits, elles s'exécutent normalement ;

• s'ils avaient été préalablement désignés dans la table de gestion, les éditeur et lecteur du schéma reçoivent les droits standards pour leur fonction. Ce point n'est pas neutre dans le cas de la restauration d'un schéma ayant fait l'objet d'une personnalisation des droits^[7] par révocation manuelle de certains privilèges de l'éditeur ou du lecteur : ces privilèges révoqués seront rétablis lors de l'import tandis que les éventuels privilèges supplémentaires seront conservés. À noter par contre que la révocation d'un privilège du producteur serait préservée, car elle fait l'objet d'une gestion différente par PostgreSQL (commande REVOKE explicite dans le script de restauration).

Avec psql, sauf à se connecter avec un rôle super-utilisateur^[3] (ce qui fonctionnera toujours), il faudra désigner expressément le rôle de groupe^[4] qui deviendra producteur^[1] des nouveaux schémas. Il va sans dire que l'utilisateur doit être membre du rôle de groupe choisi.

Avec la console interactive psql, il s’agira simplement de lancer une commande SET ROLE avant l’import.

SET ROLE %nom_du_producteur ;

SET ROLE %nom_du_producteur ;

Si psql est utilisé en ligne de commande, et seulement à partir de PostgreSQL 9.6, il est possible d'ajouter une commande -c "SET ROLE %nom_du_producteur" avant la commande d’import -f.

Plus précisément, cette combinaison de commandes -c et -f apparaît avec l’exécutable psql de la version 9.6. Cependant, la rétro-compatibilité étant assurée, il est parfaitement envisageable d’utiliser le terminal psql de la version 9.6 ou 10 pour importer des données sur un serveur sous PostgreSQL 9.5.

Il est également possible d’ajouter la commande SET ROLE au début du script SQL, si le volume du fichier permet sa manipulation dans un éditeur de texte. Cette méthode fonctionne quelle que soit la version de PostgreSQL.

S’il n’est pas du tout envisageable de modifier le rôle propriétaire des schémas, par exemple parce que c’est le script d’import lui-même qui lance des requêtes illicites désignant un rôle de connexion comme producteur, une solution alternative consiste à :

1. désactiver temporairement ASGARD le temps de l’import (cf. Désactiver ASGARD ?) ;

2. modifier a posteriori le propriétaire des schémas importés en désignant cette fois un rôle de groupe et non plus un rôle de connexion ;

3. référencer^[5] les schémas (et nettoyer les droits par la même occasion) avec la fonction asgard_initialise_schema.

D’une manière générale, il est déconseillé d’exécuter des scripts provenant de sources externes qui ne soient pas au format texte (et donc exécutables avec psql), dans la mesure où leur contenu et son innocuité pour la base de données ne peuvent être vérifiés.

Nonobstant, avec pg_restore, on pourra utiliser --role=%nom_role_producteur pour désigner le rôle de groupe^[4] producteur^[1] des schémas importés. Cette fonction a précisément pour effet d’exécuter une commande SET ROLE %nom_role_producteur avant de commencer la restauration des données.

Le rôle de connexion de l'utilisateur doit être membre du rôle de groupe choisi.

Comme avec psql, il reste également possible de se connecter en tant que super-utilisateur^[3] ou de désactiver temporairement ASGARD (ce qui est toutefois déconseillé). On notera que pg_restore a une option -O (forme longue --no-owner) qui permet de se prémunir contre les commandes qui attribueraient inopportunément la propriété des schémas à un rôle de connexion.

La fonctionnalité de restauration de schéma de pgAdmin utilise pg_restore et offre donc les mêmes possibilités pour désigner le rôle de groupe^[4] qui sera producteur^[1] du schéma.