Оскільки об'єкти в pg_catalogсхемі неявно перебувають у search_path( docs ), чи рекомендується встановити розширення в цій схемі?

Не встановлюйте розширень pg_catalog(якщо це не їх по замовчуванням: далеко не всі розширення розроблені таким чином), тому що ви не заплуталися з каталогом системи, коли - небудь . @Chris демонструє одну з причин. Є й інші.

Однак схема "громадськості" жодним чином не особлива . Це просто схема за замовчуванням, яка попередньо встановлена ​​у стандартних дистрибутивах, щоб ми могли розпочати роботу відразу. Деякі адміністратори БД взагалі не використовують загальнодоступну схему, деякі навіть видаляють її.

CREATE EXTENSIONне належить до "публічної" схеми. Він встановлюється в поточну схему, якщо не вказано інше - за винятком деяких розширень, заздалегідь встановленою схемою (наприклад, PGQ / Londiste ). Документація:

схема_назви

Назва схеми, в якій встановлюються об'єкти розширення, враховуючи, що розширення дозволяє переміщувати його вміст. Названа схема повинна вже існувати. Якщо не вказано, а також файл керування розширення не визначає схему, використовується поточна схема створення об'єктів за замовчуванням .

Пам’ятайте, що саме розширення не вважається в рамках жодної схеми: розширення мають некваліфіковані імена, які повинні бути унікальними для всієї бази даних. Але об'єкти, що належать до розширення, можуть бути в схемах.

Сміливий акцент мій.
Вирішіть, як керувати користувачами, схемами та search_path:

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

Потім вирішіть, де встановити розширення. Ви можете встановити будь-яку схему на ваш вибір і включити цю схему за замовчуванням search_pathдля всіх користувачів або лише для деяких або взагалі відсутніх користувачів (так що необхідні кваліфіковані посилання). Все залежить від того, чого ви хочете досягти.
Що б ви не робили, залишайтеся послідовними.

Мені подобається встановлювати розширення (які це дозволяють) у спеціальній схемі "розширення", яку я включаю за замовчуванням search_path після "public" (і "$ user" - якщо ви використовуєте це). Допомагає чітко розділити власні публічні функції та інші суспільні об’єкти. Моє налаштування в postgresql.conf:

search_path = "$user",public,extensions

Або:

search_path = public,extensions

І я встановлюю розширення за допомогою:

CREATE EXTENSION some_extension SCHEMA extensions;

Варто зазначити одне: таким чином ви можете «заховати» (некваліфіковані) об’єкти у extensionsсхемі за однойменними об’єктами (та параметрами) у publicсхемі.

Пов'язані:

• Найкращий спосіб встановити hstore на декілька схем у базі даних Postgres?
• Як я можу підробити inet_client_addr () для одиничних тестів у PostgreSQL?

pg_catalogНаскільки мені відомо, встановлення розширень не рекомендується. Ви повинні використовувати publicсхему за замовчуванням , яка також є search_pathза замовчуванням.

Чому?

Як приклад, я буду працювати з pageinspectрозширенням, яке я вже створив у publicсхемі. Усі функції за замовчуванням доступні для всіх схем у базі даних, якщо вони знаходяться в publicсхемі.

Тепер я намагаюся перемістити його до pg_catalogсхеми, використовуючи

ALTER EXTENSION pageinspect SET SCHEMA pg_catalog;

і це працює чудово.

Але ...

Спробуйте перемістити його знову, повернутися до publicсхеми за допомогою

ALTER EXTENSION pageinspect SET SCHEMA public;

і це не дозволить, спричинивши наступну помилку

ERROR: cannot remove dependency on schema pg_catalog because it is a system object
SQL state: 0A000

Ой-ой! Що ж, це нормально, що це не дозволить мені перенести це. Я просто можу повернути його назад до publicсхеми, скинувши його та знову створивши, правда? ...

DROP EXTENSION pageinspect;
CREATE EXTENSION pageinspect;

ОК добре. Поверніться в правильне місце в publicсхемі, і функції досі доступні для всіх схем бази даних.

TL, DR; Просто використовуйте publicсхему за замовчуванням для розширень.