Ponieważ obiekty w pg_catalogschemacie są domyślnie zawarte w search_path( dokumentach ), czy zaleca się instalowanie rozszerzeń w tym schemacie?

Nie należy instalować rozszerzenia pg_catalog(chyba, że jest ich domyślnie: bardzo niewielu rozszerzenia są zaprojektowane w ten sposób), ponieważ nie zadzieraj z katalogu systemowego, kiedykolwiek . @Chris pokazuje jeden powód. Są inni.

Jednak schemat „publiczny” nie jest w żaden sposób wyjątkowy . To tylko domyślny schemat, który jest wstępnie zainstalowany w standardowych dystrybucjach, abyśmy mogli zacząć od razu. Niektórzy administratorzy DB w ogóle nie używają schematu „publicznego”, niektórzy nawet go usuwają.

CREATE EXTENSIONnie jest powiązany ze schematem „publicznym”. Instaluje się w bieżącym schemacie, chyba że zalecono inaczej - z wyjątkiem niektórych rozszerzeń, które mają wstępnie ustawiony schemat (np. PGQ / Londiste ). Dokumentacja:

nazwa_schematu

Nazwa schematu, w którym należy zainstalować obiekty rozszerzenia, biorąc pod uwagę, że rozszerzenie pozwala na przeniesienie jego zawartości. Nazwany schemat musi już istnieć. Jeśli nie zostanie określony, a plik kontrolny rozszerzenia również nie określa schematu, używany jest bieżący domyślny schemat tworzenia obiektów .

Pamiętaj, że samo rozszerzenie nie jest uważane za objęte żadnym schematem: rozszerzenia mają niekwalifikowane nazwy, które muszą być unikalne dla całej bazy danych. Ale obiekty należące do rozszerzenia mogą znajdować się w schematach.

Odważny nacisk moje.
Zdecyduj, jak zarządzać użytkownikami, schematami i search_path:

• W jaki sposób ścieżka szukania wpływa na rozdzielczość identyfikatora i „bieżący schemat”

Następnie zdecyduj, gdzie zainstalować rozszerzenia. Możesz zainstalować na dowolnym wybranym schemacie i dołączyć ten schemat jako domyślny search_pathdla wszystkich użytkowników lub tylko dla niektórych użytkowników lub wcale (tak, że wymagane są kwalifikowane referencje). Wszystko zależy od tego, co chcesz osiągnąć.
Cokolwiek robisz, pozostań konsekwentny.

Lubię instalować rozszerzenia (które na to pozwalają) w dedykowanym schemacie „rozszerzeń”, które dołączam do domyślnego search_path po „public” (i „$ user” - jeśli go używasz). Pomaga w czystym oddzieleniu moich własnych funkcji publicznych i innych obiektów publicznych. Moje ustawienie w postgresql.conf:

search_path = "$user",public,extensions

Lub:

search_path = public,extensions

I instaluję rozszerzenia z:

CREATE EXTENSION some_extension SCHEMA extensions;

Należy zwrócić uwagę: W ten sposób można „ukryć” (niekwalifikowane) obiekty w extensionsschemacie za obiektami o tej samej nazwie (i parametrach) w publicschemacie.

Związane z:

• Najlepszy sposób na zainstalowanie hstore na wielu schematach w bazie danych Postgres?
• Jak mogę sfałszować inet_client_addr () do testów jednostkowych w PostgreSQL?

pg_catalogO ile mi wiadomo, instalowanie rozszerzeń nie jest zalecane. Powinieneś użyć domyślnego publicschematu, który również jest search_pathdomyślnie.

Dlaczego?

Jako przykład będę pracować z pageinspectrozszerzeniem, które już utworzyłem w ramach publicschematu. Wszystkie funkcje są domyślnie dostępne dla wszystkich schematów w bazie danych, jeśli znajdują się w publicschemacie.

Teraz próbuję przenieść go do pg_catalogschematu, używając

ALTER EXTENSION pageinspect SET SCHEMA pg_catalog;

i działa dobrze.

Ale...

Spróbuj przenieść go ponownie, publicużywając schematu

ALTER EXTENSION pageinspect SET SCHEMA public;

i nie pozwoli na to, powodując następujący błąd

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

O o! Cóż, to w porządku, że nie pozwoli mi to przenieść. Mogę po prostu przywrócić go do publicschematu, upuszczając go i tworząc ponownie, prawda? ...

DROP EXTENSION pageinspect;
CREATE EXTENSION pageinspect;

Ok dobrze. Po powrocie na właściwe miejsce w publicschemacie funkcje są nadal dostępne dla wszystkich schematów w bazie danych.

TL, DR; Po prostu użyj domyślnego publicschematu dla rozszerzeń.