9.19. Fonctions d'information sur le système

Tableau 9-39 affiche plusieurs fonctions qui extraient des informations de la session et du système.

session_user est habituellement l'utilisateur utilisé pour la connexion à la base de données ; mais les superutilisateurs peuvent modifier ce paramètrage avec SET SESSION AUTHORIZATION. current_user est l'identifieur de l'utilisateur, applicable pour les vérifications de droits. Normalement, il est identique à l'utilisateur de la session mais il change pendant l'exécution des fonctions avec l'attribut SECURITY DEFINER. Dans le parlé Unix, l'utilisateur de la session est le << real user >> (NdT : l'utilisateur réel) et l'utilisateur en cours est l'<< effective user >> (NdT : l'utilisateur effectif) .

current_schema renvoit le nom du premier schéma sur le chemin de recherche (ou une valeur NULL si ce dernier est vide). C'est le schéma qui sera utilisé pour toute table ou autre objet nommé créé sans spécifier de schéma cible. current_schemas(boolean) renvoit un tableau de noms avec tous les schémas du chemin de recherche. L'option booléenne détermine si les schémas système inclus implicitement comme pg_catalog sont inclus dans le chemin de recherche renvoyé.

inet_client_addr renvoit l'adresse IP du client en cours et inet_client_port renvoit le numéro du port. inet_server_addr renvoit l'adresse IP sur laquelle le serveur a accepté la connexion en cours et inet_server_port renvoit le numéro du port. Toutes ces fonctions renvoient NULL si la connexion en cours s'est établie via un socket de domaine Unix.

version() renvoit une chaîne décrivant la version du serveur PostgreSQL.

Tableau 9-40 liste les fonctions qui permettent aux utilisateurs de demander les droits d'accès. Voir Section 5.7 pour plus d'informations sur les droits.

has_table_privilege vérifie si l'utilisateur peut accèder à une table d'une façon particulière. L'utilisateur peut être spécifié par son nom ou par son ID (pg_user.usesysid). Si l'argument est omis, current_user est supposé. La table peut être spécifiée par nom ou par OID. (Du coup, il n'y a que six variantes de has_table_privilege pouvant être distingué par leur nombre et le types de leurs arguments.) En spécifiant un nom, il est possible de le qualifier par celui du schéma si nécessaire. Le type de droit d'accès désiré est spécifié par une chaîne de texte qui doit être évalué par une des valeurs SELECT, INSERT, UPDATE, DELETE, RULE, REFERENCES ou TRIGGER. (Néanmoins, la casse de la chaîne n'est pas significative.) Voici un exemple :

          SELECT has_table_privilege('myschema.mytable', 'select');
        

has_database_privilege vérifie si l'utilisateur peut accèder à une base de données d'une façon particulière. Les possibilités pour ses arguments sont analogues à has_table_privilege. Le type de droit d'accès désiré doit être évalué à CREATE, TEMPORARY ou TEMP (ce qui est équivalent à TEMPORARY).

has_function_privilege vérifie si un utilisateur peut accèder à une fontion d'une façon particulière. Les possibilités pour ses arguments sont analogues à has_table_privilege. En spécifiant une fonction par une chaîne texte plutôt que par son OID, l'entrée autorisée est identique au type de données regprocedure (voir Section 8.12). Le type de droit d'accès désiré doit s'évaluer à EXECUTE. Voici un exemple :

          SELECT has_function_privilege('joeuser', 'myfunc(int, text)', 'execute');
        

has_language_privilege vérifie si un utilisateur peut accèder à un langage de procédures d'une façon particulière. Les possibilités pour ses arguments sont analogues à has_table_privilege. Le type de droit d'accès désiré doit s'évaluer à USAGE.

has_schema_privilege vérifie si un utilisateur peut accèder à un schéma d'une façon particulière. Les possibilités pour ses arguments sont analogues à has_table_privilege. Le type de droit d'accès désiré doit s'évaluer à CREATE ou USAGE.

has_tablespace_privilege vérifie si un utilisateur peut accèder à un espace logique d'une façon particulière. Les possibilités pour ses arguments sont analogues à has_table_privilege. Le type de droit d'accès désiré doit s'évaluer à CREATE.

Pour tester si un utilisateur détient une option grant sur le droit, ajoutez WITH GRANT OPTION au mot clé du droit ; par exemple 'UPDATE WITH GRANT OPTION'.

Tableau 9-41 affiche les fonctions qui déterminent si un certain objet est visible dans le chemin de recherche en cours. Une table est dite visible si son schéma contenant est dans le chemin de recherche et qu'aucune table du même nom apparaît avant dans le chemin de recherche. Ceci est équivalent à au fait que la table peut être référencée par nom sans qualification explicite de schéma. Par exemple, pour lister les noms de toutes les tables visibles :

          SELECT relname FROM pg_class WHERE pg_table_is_visible(oid);
        

pg_table_is_visible réalise la vérification pour les tables (ou vues, ou tout autre type d'entrée dans pg_class). pg_type_is_visible, pg_function_is_visible, pg_operator_is_visible, pg_opclass_is_visible et pg_conversion_is_visible réalisent le même type de vérification de visibilité pour les types (et domaines), les fonctions, les opérators, les classes d'opérateur et les conversions, respectivement. Pour les fonctions et opérateurs, un objet dans le chemin de recherche est visible s'il n'y a aucun objet du même nom et de même type de données pour les arguments précédemment dans le chemin. Pour les classes d'opérateur, les méthodes d'accès par le nom et par l'index associé sont considérées.

Toutes ces fonctions nécessitent que les OID des objets identifient l'objet à vérifier. Si vous voulez tester un objet par son nom, il est préférable d'utiliser les types d'alias d'OID (regclass, regtype, regprocedure ou regoperator), par exemple

  SELECT pg_type_is_visible('myschema.widget'::regtype);

Notez qu'il n'y aurait aucun sens à tester un nom non qualifié de cette façon — si le nom peut être reconnu, il doit être visible.

Tableau 9-42 liste les fonctions qui extraient des informations à partir des catalogues système.

format_type renvoit le nom SQL d'un type de données qui est identifié par son OID de type et peut-être par un modificateur de type. Passez NULL au modificateur de type si aucun modificateur spécifique n'est connu.

pg_get_viewdef, pg_get_ruledef, pg_get_indexdef, pg_get_triggerdef et pg_get_constraintdef reconstruisent la commande de création pour, respectivement, une vue, une règle, un index, un déclencheur ou une contrainte. (Notez que ceci est une reconstruction décompilée, pas le texte original de la commande.) pg_get_expr décompile la forme interne d'une expression individuelle, comme la valeur par défaut d'une colonne. Cela pourrait être utilisé lors de l'examen du contenu des catalogues systèmes. La plupart de ces fonctions viennent en deux variantes, une qui peut << afficher joliment >> le résultat (en option). Ce format est plus lisible mais le format par défaut a plus de chances d'être interprété de la même façon par les versions futures de PostgreSQL ; évitez d'utiliser ce format pour réaliser des sauvegardes. Passer false pour le paramètre de joli affichage renvoit le même résultat que la variante qui n'a pas ce paramètre.

pg_get_userbyid extrait le nom d'un utilisateur à partir de son identifiant. pg_get_serial_sequence récupère le nom de la séquence associée avec une colonne de type serial ou bigserial. Le nom est convenablement formaté pour être passé aux fonctions sur les séquences (voir Section 9.12). NULL est renvoyé si la colonne n'a pas de séquence attachée.

pg_tablespace_databases autorise l'examen de l'usage d'un espace logique. Elle renverra un ensemble d'OID des bases de données contenant des objets dans l'espace logique. Si cette fonction renvoit des lignes, l'espace logique n'est pas vide et ne peux pas être supprimé. Pour afficher les objets spécifiques peuplant l'espace logique, vous aurez besoin de vous connecter aux bases de données identifiées par pg_tablespace_databases et de demander leurs catalogues pg_class.

Les fonctions affichées dans Tableau 9-43 extraient des commentaires stockés précédemment avec la commande COMMENT. Une valeur NULL est renvoyée si aucun commentaire ne correspond aux paramètres spécifiés.

La forme à deux paramètres de obj_description renvoit le commentaire d'un objet de la base de données, spécifié par son OID et le nom du catalogue système le contenant. Par exemple, obj_description(123456,'pg_class') récupèrerait le commentaire pour une table d'OID 123456. La forme à un paramètre de obj_description requiert seulement l'OID de l'objet. Elle est maintenant obsolète car il n'existe aucune garantie que les OID soient uniques au travers des différents catalogues système ; du coup, un mauvais commentaire pourrait être renvoyé.

col_description renvoit un commentaire pour une colonne de la table, spécifié par l'OID de la table et le numéro de la colonne. obj_description ne peut pas être utilisé pour les colonnes de table car les colonnes ne disposent d'OID.