PostgreSQL
 sql >> Datenbank >  >> RDS >> PostgreSQL

Wie beeinflusst der Suchpfad die Identifikatorauflösung und das aktuelle Schema

Was ist der Schemasuchpfad search_path ?

Das Handbuch:

[...] Tabellen werden oft mit unqualifizierten Namen bezeichnet, die nur aus dem Tabellennamen bestehen. Das System bestimmt, welche Tabelle gemeint ist, indem es einem Suchpfad folgt, der eine Liste von zu durchsuchenden Schemas ist .

Fette Hervorhebung von mir. Dies erklärt die Kennungsauflösung .

Das "aktuelle Schema" (oder „Standardschema“) ist laut Dokumentation:

Das erste im Suchpfad benannte Schema wird das aktuelle Schema genannt . Abgesehen davon, dass es das erste durchsuchte Schema ist, ist es auch das Schema, in dem neue Tabellen erstellt werden, wenn CREATE TABLE Befehl gibt keinen Schemanamen an.

Fette Hervorhebung von mir. Die Systemschemas pg_temp (Schema für temporäre Objekte der aktuellen Sitzung) und pg_catalog sind automatisch Teil des Suchpfades und werden zuerst durchsucht , in dieser Reihenfolge. Das Handbuch:

pg_catalog ist immer effektiv Teil des Suchpfads. Wenn es nicht explizit im Pfad genannt wird, wird implizit vorher gesucht Durchsuchen der Schemas des Pfads. Dadurch wird sichergestellt, dass integrierte Namen immer auffindbar sind. Sie können pg_catalog jedoch explizit platzieren am Ende Ihres Suchpfads, wenn Sie es vorziehen, dass benutzerdefinierte Namen integrierte Namen überschreiben.

Fette Hervorhebung wie im Original. Und pg_temp kommt davor, es sei denn, es wird an eine andere Position gebracht.

Wie wird es eingestellt?

Es gibt verschiedene Möglichkeiten, die Laufzeitvariable search_path zu setzen .

  1. Legen Sie einen Cluster fest -weiter Standardwert für alle Rollen in allen Datenbanken in postgresql.conf (und neu laden). Vorsicht damit!

    search_path = 'blarg,public'

    Die ausgelieferte Standardeinstellung für diese Einstellung ist:

    search_path = "$user",public

    Das erste Element gibt an, dass ein Schema mit dem gleichen Namen wie der aktuelle Benutzer gesucht werden soll. Existiert kein solches Schema, wird der Eintrag ignoriert.

  2. Legen Sie es als Standard für eine Datenbank fest :

    ALTER DATABASE test SET search_path = blarg,public;

  3. Legen Sie es als Standard für die Rolle fest Sie verbinden sich mit (effektiv clusterweit):

    ALTER ROLE foo SET search_path = blarg,public;

  4. Oder sogar (oft am besten!) als Standard für eine Rolle in einer Datenbank :

    ALTER ROLE foo IN DATABASE test SET search_path = blarg,public;

  5. Schreiben Sie den Befehl an den Anfang Ihres Skripts. Oder führen Sie es in Ihrer DB-Sitzung aus :

    SET search_path = blarg,public;

  6. Legen Sie einen bestimmten search_path fest für den Umfang einer Funktion (um vor böswilligen Benutzern mit ausreichenden Berechtigungen geschützt zu sein). Lesen Sie mehr über das Schreiben von SECURITY DEFINER Funktionen sicher im Handbuch.

CREATE FUNCTION foo() RETURNS void AS
$func$
BEGIN
   -- do stuff
END
$func$ LANGUAGE plpgsql SECURITY DEFINER
       SET search_path=blarg,public,pg_temp;

Eine höhere Nummer in meiner Liste übertrumpft eine niedrigere Nummer.
Das Handbuch hat noch mehr Möglichkeiten , wie das Setzen von Umgebungsvariablen oder die Verwendung von Befehlszeilenoptionen.

So sehen Sie die aktuelle Einstellung:

SHOW search_path;

Zurücksetzen:

RESET search_path;

Das Handbuch:

Der Defaultwert ist definiert als der Wert, den der Parameter gehabt hätte, wenn kein SET gewesen wäre jemals in der aktuellen Session dafür ausgegeben wurde.