ASGARD

Avec la version 1.4.0, le pseudo-rôle public et, par suite, tous les rôles du serveur :

• accèdent en lecture à toutes les tables et vues du schéma utilisateur z_asgard, notamment celles qui servent aux plugins QGIS AsgardManager et AsgardMenu.

• peuvent éditer les vues gestion_schema_usr et gestion_schema_etr de ce schéma.

Ce changement rend obsolètes plusieurs contraintes précédemment imposées par ASGARD :

• Il n'est plus nécessaire de rendre les rôles des utilisateurs d'AsgardManager et AsgardMenu membres de g_consult ou du rôle lecteur du schéma z_asgard. Tous les rôles du serveurs ont désormais accès aux données nécessaires au fonctionnement de ces plugins.

• Les rôles producteurs des schémas n'ont plus besoin d'être membres de g_consult ou du rôle lecteur du schéma z_asgard pour pouvoir créer ou modifier des objets dans leurs schémas.

• Les rôles habilités à gérer les schémas, c'est-à-dire ceux qui disposent du privilèges CREATE sur la base, n'ont plus à être membres de l'éditeur du schéma z_asgard pour pouvoir effectivement faire usage de ce droit.

Cette évolution n'affecte en aucune façon la sécurité du système. En particulier, si tout rôle dispose de droits d'édition sur la vue utilisateur gestion_schema_usr, il n'y voit que les schémas dont il est membre du rôle producteur, sur lesquels il est donc légitime à intervenir. Idem pour la vue technique gestion_schema_etr.

Référence GitHub : issue #5.

La seconde simplification notable apportée par la version 1.4 est la disparation de la contrainte qui, pour désigner comme producteur d'un schéma un rôle dont g_admin n'est pas encore membre, obligeait à disposer de l'attribut CREATEROLE ou à être membre dudit rôle avec ADMIN OPTION.

Avec les versions antérieures, effacer définitivement un schéma inactif^[2] de la table de gestion nécessitait d'un rôle non membre de g_admin[4] qu'il dispose du privilège CREATE sur la base ou soit exactement le rôle producteur^[3] du schéma. Les rôles membres du producteur n'étaient pas pris en compte.

Cette limitation était essentiellement une facilité technique. Le rôle renseigné dans le champ producteur de la table de gestion pour un schéma inactif n'existe pas nécessairement et les fonctions proposées par PostgreSQL pour contrôler l'appartenance d'un rôle à un autre échouent si l'un des rôles n'existe pas, il était donc plus simple de ne pas utiliser ce critère, même s'il aurait été le plus logique.

La version 1.4.0 d'ASGARD met à profit la fonction asgard_has_role_usage, qui est une variante plus souple de la fonction native pg_has_role. Désormais, tout membre du producteur d'un schéma inactif hors nomenclature nationale^[5] peut effacer celui-ci de la table de gestion. Si le rôle désigné comme producteur n'existe pas, seuls les membres de g_admin pourront effacer le schéma.

Asgard prend désormais pleinement en charge les objets suivants :

• objet statistique étendu (extended planner statistics), apparu avec la version 10 de PostgreSQL ;

• classe d’opérateurs (operator class) ;

• famille d’opérateurs (operator family).

PostgreSQL ne prévoyant pas que des privilèges puissent être conférés sur ces objets, Asgard se contente d'assurer que leur propriétaire reste cohérent avec le producteur du schéma dont ils dépendent. La fonction de diagnostic z_asgard_admin.asgard_diagnostic() a toujours été en mesure de détecter les anomalies affectant ces objets. La fonction de réinitialisation des droits z_asgard.asgard_initialise_schema(text) saura maintenant les réaffecter aux producteurs de leurs schémas d'autant que de besoin.

L'extension Asgard peut dorénavant être considérée comme pleinement compatible avec toutes les fonctionnalités des versions 9.5 à 15 de PostgreSQL.

Référence GitHub : issue #6.

Correction d'une coquille dans la fonction z_asgard_admin.asgard_on_create_objet() (comparaison d'un nom d'objet avec un identifiant). Lors de la création d'un objet dans un schéma avec un producteur au nom non normalisé, Asgard considérait toujours le propriétaire de l'objet différent du producteur même lorsqu'ils étaient en fait identiques et lançait donc des commandes ALTER ... SET OWNER inutiles pour les remettre en cohérence.

Les versions antérieures d'Asgard avaient un comportement très aléatoire vis-à-vis des schémas ou rôles producteurs dont le nom comporte des guillemets. En cause, de douteuses commandes replace('"', '') parfois utilisées pour transformer des identifiants d'objets en noms. La version 1.4 les supprime et interroge les tables du catalogue système pg_namespace ou pg_roles pour obtenir le nom correspondant réellement à l'identifiant.

La fonction z_asgard.asgard_role_trans_acl(regrole), utilitaire à l'usage des autres fonctions d'Asgard et qui n'était plus utilisée depuis la version 1.3.2, est définitivement supprimée.

La suppression de schémas via des commandes DROP OWNED est désormais correctement répercutée dans la table de gestion d'Asgard (modification du déclencheur sur évènement asgard_on_drop_schema).

Les fonctions z_asgard.asgard_initialise_obj(text, text, text) et z_asgard.asgard_deplace_obj(text, text, text, text, int) deviennent plus permissives sur la saisie des noms de fonctions. Il est désormais possible d'utiliser les formes abrégées des types - int au lieu de integer, par exemple - ou encore de mettre des espaces avant ou après les virgules qui séparent les types.

La fonction de déplacement d'objet z_asgard.asgard_deplace_obj(text, text, text, text, int) vérifie maintenant qu'il n'existe pas déjà dans le schéma d'arrivée un objet de même nom que l'objet à transférer, et renvoie une erreur explicite le cas échéant. Pour une table, le contrôle porte également sur les éventuelles séquences et index qui lui sont liés, puisqu'ils changeront eux aussi de schéma.