Da Objekte im pg_catalogSchema implizit in den search_path( Dokumenten ) enthalten sind, wird empfohlen, Erweiterungen in diesem Schema zu installieren?

Installieren Sie keine Erweiterungen für pg_catalog(es sei denn, dies ist die Standardeinstellung: Nur sehr wenige Erweiterungen sind so konzipiert), da Sie niemals mit dem Systemkatalog herumspielen . @ Chris zeigt einen Grund warum. Da sind andere.

Das "öffentliche" Schema ist jedoch keineswegs etwas Besonderes . Es ist nur das Standardschema, das in Standarddistributionen vorinstalliert ist, damit wir sofort loslegen können. Einige DB-Administratoren verwenden das "öffentliche" Schema überhaupt nicht, andere löschen es sogar.

CREATE EXTENSIONist nicht mit dem "öffentlichen" Schema verbunden. Es wird in das aktuelle Schema installiert, sofern nicht anders angegeben - außer einige Erweiterungen haben ein voreingestelltes Schema (wie PGQ / Londiste ). Die Dokumentation:

Schemaname

Der Name des Schemas, in dem die Objekte der Erweiterung installiert werden sollen, vorausgesetzt, die Erweiterung ermöglicht das Verschieben des Inhalts. Das benannte Schema muss bereits vorhanden sein. Wenn nicht angegeben und die Steuerdatei der Erweiterung auch kein Schema angibt, wird das aktuelle Standardschema für die Objekterstellung verwendet .

Denken Sie daran, dass die Erweiterung selbst nicht in einem Schema enthalten ist: Erweiterungen haben nicht qualifizierte Namen, die datenbankweit eindeutig sein müssen. Objekte, die zur Erweiterung gehören, können sich jedoch in Schemas befinden.

Meine kühne Betonung.
Entscheiden Sie, wie Benutzer, Schemas und Folgendes verwaltet werden sollen search_path:

• Wie beeinflusst der Suchpfad die Auflösung der Kennung und das „aktuelle Schema“?

Entscheiden Sie dann , wo Erweiterungen installiert werden sollen. Sie können in ein beliebiges Schema Ihrer Wahl installieren und dieses Schema search_pathfür alle Benutzer oder nur für einige oder gar keine Benutzer in die Standardeinstellung aufnehmen (sodass qualifizierte Referenzen erforderlich sind). Es hängt alles davon ab, was Sie erreichen möchten.
Was auch immer Sie tun, bleiben Sie konsequent.

Ich installiere gerne Erweiterungen (die dies zulassen) in einem dedizierten "Erweiterungs" -Schema, das ich in der Standardeinstellung search_path nach "public" (und "$ user" - wenn Sie das verwenden) einbinde. Hilft bei einer sauberen Trennung meiner eigenen öffentlichen Funktionen und anderer öffentlicher Objekte. Meine Einstellung in postgresql.conf:

search_path = "$user",public,extensions

Oder:

search_path = public,extensions

Und ich installiere Erweiterungen mit:

CREATE EXTENSION some_extension SCHEMA extensions;

Eines ist zu beachten: Auf diese Weise können Sie (nicht qualifizierte) Objekte im extensionsSchema hinter gleichnamigen Objekten (und Parametern) im publicSchema "verstecken" .

Verbunden:

• Der beste Weg, um hstore auf mehreren Schemas in einer Postgres-Datenbank zu installieren?
• Wie kann ich inet_client_addr () für Unit-Tests in PostgreSQL fälschen?

Das Installieren von Erweiterungen in pg_catalogwird meines Wissens nicht empfohlen. Sie sollten das Standardschema verwenden public, das sich ebenfalls im search_pathStandardschema befindet.

Warum?

Als Beispiel werde ich mit der pageinspectErweiterung arbeiten, die ich bereits im publicSchema erstellt habe. Alle Funktionen sind standardmäßig für alle Schemas in der Datenbank zugänglich, wenn sie sich im publicSchema befinden.

Jetzt versuche ich, es mit in das pg_catalogSchema zu verschieben

ALTER EXTENSION pageinspect SET SCHEMA pg_catalog;

und es funktioniert gut.

Aber...

Versuchen Sie erneut, es mit in das publicSchema zu verschieben

ALTER EXTENSION pageinspect SET SCHEMA public;

und es wird es nicht zulassen, was den folgenden Fehler ergibt

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

Oh oh! Nun, das ist in Ordnung, dass ich es nicht bewegen kann. Ich kann es einfach wieder in das publicSchema aufnehmen, indem ich es ablege und neu erstelle, oder? ...

DROP EXTENSION pageinspect;
CREATE EXTENSION pageinspect;

OK gut. Zurück an der richtigen Stelle im publicSchema, und die Funktionen sind weiterhin für alle Schemas in der Datenbank zugänglich.

TL, DR; Verwenden Sie einfach das Standardschema publicfür Erweiterungen.