5.7.3. The Schema Search Path

Gekwalificeerde namen zijn vervelend om te schrijven, en het is vaak beter om een bepaalde schema naam toch niet in applicaties te gebruiken. Daarom wordt vaak naar tabellen verwezen met ongekwalificeerde namen, die alleen uit de tabelnaam bestaan. Het systeem bepaalt welke tabel bedoeld wordt door een zoekpad te volgen, wat een lijst van schema’s is om in te zoeken. De eerste overeenkomende tabel in het zoekpad wordt genomen om de gewenste tabel te zijn. Als er geen overeenkomst in het zoekpad is, wordt er een fout gemeld, zelfs als er overeenkomstige tabelnamen bestaan in andere schema’s in de database.

De mogelijkheid om objecten met dezelfde naam in verschillende schema’s te maken, maakt het schrijven van een query die elke keer naar precies dezelfde objecten verwijst eenvoudiger. Het opent ook de mogelijkheid voor gebruikers om het gedrag van query’s van andere gebruikers te veranderen, met kwade opzet of per ongeluk. Vanwege het gebruik van ongekwalificeerde namen in queries en hun gebruik in PostgreSQLinternals, vertrouwt het toevoegen van een schema aan search_patheffectief alle gebruikers met CREATEprivilege op dat schema. Wanneer u een gewone query uitvoert, kan een kwaadwillende gebruiker die in staat is om objecten in een schema van uw zoekpad te maken, de controle overnemen en willekeurige SQL-functies uitvoeren alsof u ze zelf heeft uitgevoerd.

Het eerste schema dat in het zoekpad wordt genoemd, wordt het currentschema genoemd. Behalve dat dit het eerste schema is waarin wordt gezocht, is het ook het schema waarin nieuwe tabellen zullen worden aangemaakt als het CREATE TABLE commando geen schemanaam specificeert.

Om het huidige zoekpad te tonen, gebruikt u het volgende commando:

SHOW search_path;

In de standaardinstelling geeft dit als resultaat:

 search_path-------------- "$user",public

Het eerste element specificeert dat een schema met dezelfde naam als de huidige gebruiker moet worden doorzocht. Als zo’n schema niet bestaat, wordt de invoer genegeerd. Het tweede element verwijst naar het publieke schema dat we al gezien hebben.

Het eerste schema in het zoekpad dat bestaat, is de standaardlocatie voor het maken van nieuwe objecten. Dat is de reden dat objecten standaard in het openbare schema worden gecreëerd. Wanneer naar objecten wordt verwezen in een andere context zonder schema-kwalificatie (tabelmodificatie, gegevensmodificatie of query-opdrachten) wordt het zoekpad doorlopen totdat een overeenkomend object is gevonden. Daarom kan in de standaardconfiguratie elke ongekwalificeerde toegang weer alleen naar het publieke schema verwijzen.

Om ons nieuwe schema in het pad te zetten, gebruiken we:

SET search_path TO myschema,public;

(We laten de $user hier weg omdat we die niet direct nodig hebben.) En dan hebben we toegang tot de tabel zonder schema-kwalificatie:

DROP TABLE mytable;

Ook, omdat mijnschema het eerste element in het pad is, zouden nieuwe objecten standaard init.

We hadden ook kunnen schrijven:

SET search_path TO myschema;

Dan hebben we geen toegang meer tot het publieke schema zonder expliciete kwalificatie. Er is niets speciaals aan het publicschema, behalve dat het standaard bestaat. Het kan ook worden verwijderd.

Zie ook Paragraaf 9.25 voor andere manieren om het schema zoekpad te manipuleren.

Het zoekpad werkt op dezelfde manier voor datatype namen, functie namen, en operator namen als het doet voor tabel namen. Datatype en functie namen kunnen op precies dezelfde manier gekwalificeerd worden als tabel namen. Als u een gekwalificeerde operatornaam in een uitdrukking moet schrijven, is er een speciale bepaling: u moet schrijven

OPERATOR(schema.operator)

Dit is nodig om syntactische ambiguïteit te vermijden. Een voorbeeld is:

SELECT 3 OPERATOR(pg_catalog.+) 4;

In de praktijk vertrouwt men meestal op het zoekpad voor operatoren,om niet zoiets lelijks te hoeven schrijven.

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.