5.7.3. Der Schema-Suchpfad
Qualifizierte Namen sind mühsam zu schreiben, und es ist oft besser, einen bestimmten Schemanamen nicht in Anwendungen zu verwenden. Daher wird auf Tabellen oft mit unqualifizierten Namen verwiesen, die nur aus dem Tabellennamen bestehen. Das System bestimmt, welche Tabelle gemeint ist, indem es einem Suchpfad folgt, der eine Liste von Schemas enthält, in denen gesucht werden soll. Wenn es im Suchpfad keine Übereinstimmung gibt, wird ein Fehler gemeldet, auch wenn übereinstimmende Tabellennamen in anderen Schemas in der Datenbank existieren.
Die Möglichkeit, gleichnamige Objekte in verschiedenen Schemas zu erstellen, erschwert das Schreiben einer Abfrage, die jedes Mal auf genau dieselben Objekte verweist. Außerdem eröffnet sie den Benutzern die Möglichkeit, das Verhalten der Abfragen anderer Benutzer böswillig oder versehentlich zu ändern. Aufgrund der weiten Verbreitung von unqualifizierten Namen in Abfragen und ihrer Verwendung in PostgreSQL-Interna wird durch das Hinzufügen eines Schemas zu search_patheffectively allen Benutzern vertraut, die das CREATE-Recht für dieses Schema haben. Wenn Sie eine gewöhnliche Abfrage ausführen, kann ein böswilliger Benutzer, der in der Lage ist, Objekte in einem Schema Ihres Suchpfads zu erstellen, die Kontrolle übernehmen und beliebige SQL-Funktionen ausführen, als ob Sie sie ausgeführt hätten.
Das erste Schema, das im Suchpfad genannt wird, wird als aktuelles Schema bezeichnet. Es ist nicht nur das erste Schema, das durchsucht wird, sondern auch das Schema, in dem neue Tabellen erstellt werden, wenn der Befehl CREATE TABLE keinen Schemanamen angibt.
Um den aktuellen Suchpfad anzuzeigen, verwenden Sie den folgenden Befehl:
SHOW search_path;
In der Standardkonfiguration wird Folgendes zurückgegeben:
search_path-------------- "$user",public
Das erste Element gibt an, dass ein Schema mit dem gleichen Namen wie der aktuelle Benutzer durchsucht werden soll. Wenn kein solches Schema existiert, wird der Eintrag ignoriert. Das zweite Element verweist auf das öffentliche Schema, das wir bereits gesehen haben.
Das erste Schema im Suchpfad, das existiert, ist der Standardort für die Erstellung neuer Objekte. Das ist der Grund dafür, dass Objekte standardmäßig im öffentlichen Schema erstellt werden. Wenn Objekte in einem anderen Kontext ohne Schemaqualifikation referenziert werden (Tabellenmodifikation, Datenmodifikation oder Abfragebefehle), wird der Suchpfad durchlaufen, bis ein passendes Objekt gefunden wird. Daher kann in der Standardkonfiguration jeder unqualifizierte Zugriff wiederum nur auf das öffentliche Schema verweisen.
Um unser neues Schema in den Pfad einzufügen, verwenden wir:
SET search_path TO myschema,public;
(Wir lassen das $user hier weg, weil wir es nicht unmittelbar benötigen.) Und dann können wir auf die Tabelle ohne Schemaqualifikation zugreifen:
DROP TABLE mytable;
Da myschema das erste Element im Pfad ist, würden neue Objekte standardmäßig init erstellt.
Wir hätten auch schreiben können:
SET search_path TO myschema;
Dann haben wir keinen Zugriff mehr auf das öffentliche Schema ohne explizite Qualifikation. Das öffentliche Schema hat nichts Besonderes an sich, außer dass es standardmäßig vorhanden ist. Es kann auch gelöscht werden.
Siehe auch Abschnitt 9.25 für andere Möglichkeiten, den Schemasuchpfad zu manipulieren.
Der Suchpfad funktioniert für Datentypnamen, Funktionsnamen und Operatornamen auf die gleiche Weise wie für Tabellennamen. Datentyp- und Funktionsnamen können auf dieselbe Weise qualifiziert werden wie Tabellennamen. Wenn Sie einen qualifizierten Operatornamen in einen Ausdruck schreiben müssen, gibt es eine besondere Vorschrift: Sie müssen
OPERATOR(schema.operator)
schreiben, um syntaktische Mehrdeutigkeit zu vermeiden. Ein Beispiel ist:
SELECT 3 OPERATOR(pg_catalog.+) 4;
In der Praxis verlässt man sich meist auf den Suchpfad für Operatoren, um nicht so etwas Hässliches schreiben zu müssen.