Який шлях пошуку для певної бази даних та користувача?

Я можу бачити струм search_pathіз:

show search_path ;

І я можу встановити search_pathдля поточної сесії з:

set search_path = "$user", public, postgis;

Також я можу постійно встановити search_pathдля даної бази даних :

alter database mydb set search_path = "$user", public, postgis ;

І я можу назавжди встановити search_pathзадану роль (користувача) за допомогою:

alter role johnny set search_path = "$user", public, postgis ;

Але я хотів би знати, як визначити, що таке база даних та налаштування ролей (щодо search_path) перед їх зміною?

Ви можете знайти параметри конфігурації для ролей та баз даних у таблиці каталогів pg_db_role_setting.

Цей запит отримує будь-які налаштування для певної ролі чи бази даних:

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';

Якщо нічого не встановлено, наступний нижній екземпляр визначає стан за замовчуванням search_path, який є postgresql.confв цьому випадку, або параметри командного рядка при запуску сервера. Пов'язані:

• Як впливає search_path на роздільну здатність ідентифікатора та "поточну схему"

Щоб зняти будь-які параметри ролі чи бази даних - search_pathв цьому конкретному прикладі:

ALTER ROLE myrole RESET search_path;

Або:

ALTER DATABASE mydb RESET search_path;

Або:

ALTER ROLE myrole in DATABASE mydb RESET search_path;

Ніколи не маніпулюйте даними в системному каталозі ( pg_catalog.*) вручну. Використовуйте команди DDL, як вказано в посібнику для ALTER ROLEта ALTER DATABASE.
По суті, RESETкоманда видаляє рядок, pg_db_role_settingщоб дозволити знову встановити базовий параметр. Я б не називав це перекрученим.

Постійні налаштування як для баз даних, так і для ролей зберігаються в таблиці pg_db_role_settings, що відповідає загальній системі кластерів.

Присутні лише змінені налаштування. Якщо шлях пошуку ніколи не змінювався для бази даних або ролі, я думаю, це може бути припущено "$user",public.

• Значення параметра перед будь-якими змінами, в тому числі на рівні кластера (через глобальну конфігурацію postgresql.conf), можна запитувати з бази даних за допомогою:

   SELECT boot_val FROM pg_settings WHERE name='search_path';

• Значення параметра перед будь-якими змінами в межах сеансу (за допомогою SETкоманди) можна запитувати з бази даних за допомогою:

   SELECT reset_val FROM pg_settings WHERE name='search_path';

• Коли в ньому встановлено значення за замовчуванням postgresql.conf, отримати це значення в SQL незалежно від поточного сеансу нескладно . pg_settings.boot_valне буде робити, оскільки він ігнорує зміни у файлі конфігурації, а pg_settings.reset_valтакож не буде, тому що на нього впливають налаштування бази даних / користувача, які потенційно можуть бути встановлені ALTER USER/ALTER DATABASE. Найпростіший спосіб для DBA отримати значення - це просто переглянути його postgresql.conf. В іншому випадку див. Скинути параметр search_path до глобального кластеру за замовчуванням, який детально висвітлює цю тему.

select * from pg_user;

Вірно для постгресів та Redshift. Це здається занадто простим порівняно з попередніми відповідями, від яких залежать pg_db_role_setting, але у useconfigстовпці буде список конфігурацій користувача, у тому числі search_path, відформатований у вигляді списку.

pg_user Постгресова документація тут

Щоб бути більш вибірковим:

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"} │
└────────────┴─────────────────────────────────────────────────────┘

Я думаю, що ця таблиця користувачів містить усіх користувачів кластеру, а не лише конкретні db - але я цього не підтвердив.