Je peux voir le courant search_path
avec:
show search_path ;
Et je peux définir le search_path
pour la session en cours avec:
set search_path = "$user", public, postgis;
De plus, je peux définir de façon permanente le search_path
pour une base de données donnée avec:
alter database mydb set search_path = "$user", public, postgis ;
Et je peux définir définitivement le search_path
pour un rôle donné (utilisateur) avec:
alter role johnny set search_path = "$user", public, postgis ;
Mais je voudrais savoir comment déterminer le rôle de la base de données et les paramètres sont (par rapport à search_path
) avant de les modifier?
Vous pouvez trouver les paramètres de configuration des rôles et des bases de données dans la table du catalogue pg_db_role_setting
.
Cette requête récupère tous les paramètres pour un rôle ou une base de données donné:
SELECT r.rolname, d.datname, rs.setconfig
FROM pg_db_role_setting rs
LEFT JOIN pg_roles r ON r.oid = rs.setrole
LEFT JOIN pg_database d ON d.oid = rs.setdatabase
WHERE r.rolname = 'myrole' OR d.datname = 'mydb';
Si rien n'est défini, l'instance inférieure suivante détermine l'état par défaut du search_path
, lequel est postgresql.conf
dans ce cas ou des options de ligne de commande au démarrage du serveur. En relation:
Pour désactiver tout les paramètres d'un rôle ou d'une base de données - le search_path
dans cet exemple particulier:
ALTER ROLE myrole RESET search_path;
Ou:
ALTER DATABASE mydb RESET search_path;
Ou:
ALTER ROLE myrole in DATABASE mydb RESET search_path;
Ne jamais manipuler des données dans le catalogue système (pg_catalog.*
) manuellement. Utilisez les commandes DDL comme indiqué dans le manuel pour ALTER ROLE
et ALTER DATABASE
.
Essentiellement, la commande RESET
supprime une ligne de pg_db_role_setting
permettant au paramètre de base de reprendre effet. Je n'appellerais pas cela compliqué.
Les paramètres permanents des bases de données et des rôles sont stockés dans la table pg_db_role_settings du système à l'échelle du cluster.
Seuls les paramètres passés à ALTER USER
et ALTER DATABASE
sont présents dans ce tableau. Pour obtenir les valeurs configurées en dehors de ces commandes:
La valeur du paramètre avant toute modification, y compris au niveau du cluster (via la configuration globale postgresql.conf
) peut être interrogé à partir de la base de données avec:
SELECT boot_val FROM pg_settings WHERE name='search_path';
La valeur du paramètre avant toute modification dans la session (via la commande SET
) peut être interrogée à partir de la base de données avec:
SELECT reset_val FROM pg_settings WHERE name='search_path';
Lorsqu'il est défini une valeur non par défaut dans postgresql.conf
, il n'est pas simple d'obtenir cette valeur en SQL indépendamment de la session en cours . pg_settings.boot_val
ne fonctionnera pas car il ignore les modifications du fichier de configuration et pg_settings.reset_val
non plus, car il est influencé par la base de données/les paramètres utilisateur éventuellement définis par ALTER USER/ALTER DATABASE
. La façon la plus simple pour un DBA d'obtenir la valeur est de simplement la rechercher dans postgresql.conf
. Sinon, voir Réinitialiser search_path au global, cluster par défaut qui couvre ce sujet en détail.
select * from pg_user;
Vrai pour postgres et Redshift. Cela semble trop simple par rapport aux réponses précédentes qui dépendent de pg_db_role_setting
, mais la colonne useconfig
contiendra une liste de configurations utilisateur, notamment search_path
, formaté en liste.
la documentation de pg_user Postgres est ici
Pour être plus sélectif:
rs.db.batarang.com cooldb:cooldude =#> select usename
, useconfig
from pg_user
where usename = 'cooldude';
┌────────────┬─────────────────────────────────────────────────────┐
│ usename │ useconfig │
├────────────┼─────────────────────────────────────────────────────┤
│ cooldude │ {"search_path=dirt, test, \"$user\", public, prod"} │
└────────────┴─────────────────────────────────────────────────────┘
Je pense que cette table d'utilisateurs contient tous les utilisateurs du cluster, pas seulement des bases de données spécifiques - mais je n'ai pas vérifié cela.