Ponieważ obiekty w pg_catalog
schemacie są domyślnie zawarte w search_path
( dokumentach ), czy zaleca się instalowanie rozszerzeń w tym schemacie?
Ponieważ obiekty w pg_catalog
schemacie 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 EXTENSION
nie 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
:
Następnie zdecyduj, gdzie zainstalować rozszerzenia. Możesz zainstalować na dowolnym wybranym schemacie i dołączyć ten schemat jako domyślny search_path
dla 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 extensions
schemacie za obiektami o tej samej nazwie (i parametrach) w public
schemacie.
Związane z:
plpgsql
rozszerzenie jest w jakiś sposób wyjątkiem od tej reguły? Każda instalacja, którą widziałem, ma to rozszerzenie w pg_catalogIn PostgreSQL 9.0 and later, PL/pgSQL is installed by default. However it is still a loadable module, so especially security-conscious administrators could choose to remove it.
pg_catalog
. (Zgłasza błąd, jeśli spróbujesz go zmienić.) Czy to może być standard instalacji rozszerzeń języka proceduralnego dla funkcji?pg_catalog
O ile mi wiadomo, instalowanie rozszerzeń nie jest zalecane. Powinieneś użyć domyślnegopublic
schematu, który również jestsearch_path
domyślnie.Dlaczego?
Jako przykład będę pracować z
pageinspect
rozszerzeniem, które już utworzyłem w ramachpublic
schematu. Wszystkie funkcje są domyślnie dostępne dla wszystkich schematów w bazie danych, jeśli znajdują się wpublic
schemacie.Teraz próbuję przenieść go do
pg_catalog
schematu, używająci działa dobrze.
Ale...
Spróbuj przenieść go ponownie,
public
używając schematui nie pozwoli na to, powodując następujący błąd
O o! Cóż, to w porządku, że nie pozwoli mi to przenieść. Mogę po prostu przywrócić go do
public
schematu, upuszczając go i tworząc ponownie, prawda? ...Ok dobrze. Po powrocie na właściwe miejsce w
public
schemacie funkcje są nadal dostępne dla wszystkich schematów w bazie danych.TL, DR; Po prostu użyj domyślnego
public
schematu dla rozszerzeń.źródło