5.7.3. The Schema Search Path
Kvalificerede navne er kedelige at skrive, og det er ofte bedst at lade være med at skrive et bestemt skemanavn ind i programmer alligevel. Derfor refereres der ofte til tabeller ved hjælp af ukvalificerede navne, som kun består af tabellens navn. Systemet bestemmer, hvilken tabel der er tale om, ved at følge en søgesti, som er en liste over skemaer, der skal søges i. Den første matchende tabel i søgestien anses for at være den ønskede tabel. Hvis der ikke er noget match i søgestien, rapporteres der en fejl, selv om der findes matchende tabelnavne i andre skemaer i databasen.
Muligheden for at oprette objekter med samme navn i forskellige skemaer gør det kompliceret at skrive en forespørgsel, der refererer til præcis de sammeobjekter hver gang. Det åbner også mulighed for, at brugere kan ændre opførslen af andre brugeres forespørgsler, enten i ond hensigt eller ved et uheld. På grund af udbredelsen af ukvalificerede navne i forespørgsler og deres brug i PostgreSQL-internals, giver tilføjelse af et skema til search_patheffectivt tillid til alle brugere med CREATEprivilege på det pågældende skema. Når du kører en almindelig forespørgsel, kan en ondsindet bruger, der er i stand til at oprette objekter i et skema i din searchpath, overtage kontrollen og udføre vilkårlige SQL-funktioner, som om det var dig, der udførte dem.
Det første skema, der er navngivet i searchpath, kaldes det aktuelle skema. Ud over at være det første skema, der søges efter, er det også det skema, som nye tabeller oprettes i, hvis kommandoen CREATE TABLE ikke angiver et skemanavn.
For at vise den aktuelle søgesti skal du bruge følgende kommando:
SHOW search_path;
I standardopsætningen returnerer dette:
search_path-------------- "$user",public
Det første element angiver, at der skal søges efter et skema med samme navn som den aktuelle bruger. Hvis der ikke findes et sådant skema, ignoreres indtastningen. Det andet element henviser til det offentlige skema, som vi allerede har set.
Det første skema i søgestien, der findes, er standardplaceringen for oprettelse af nye objekter. Det er grunden til, at objekter som standard oprettes i det offentlige skema. Når der henvises til objekter i en anden sammenhæng uden skemakvalifikation (tabelmodifikation, datamodifikation eller forespørgselskommandoer), gennemløbes søgestien, indtil der findes et tilsvarende objekt. Derfor kan enhver ukvalificeret adgang igen i standardkonfigurationen kun henvise til det offentlige skema.
For at placere vores nye skema i stien bruger vi:
SET search_path TO myschema,public;
(Vi udelader $user her, fordi vi ikke umiddelbart har brug for det.) Og så kan vi få adgang til tabellen uden skema-kvalifikation:
DROP TABLE mytable;
Og da myschema er det første element i stien, vil nye objekter som standard blive oprettet init.
Vi kunne også have skrevet:
SET search_path TO myschema;
Så har vi ikke længere adgang til det offentlige skema uden eksplicit kvalifikation. Der er ikke noget særligt ved det offentlige skema, bortset fra at det findes som standard. Det kan også slettes.
Se også Afsnit 9.25 for andre måder at manipulere skemaets søgesti på.
Søgestien fungerer på samme måde for datatype-, funktions- og operatørnavne som for tabelnavne. Datatype- og funktionsnavne kan kvalificeres på nøjagtig samme måde som tabelnavne. Hvis du skal skrive et kvalificeret operatørnavn i et udtryk, er der en særlig bestemmelse: du skal skrive
OPERATOR(schema.operator)
Dette er nødvendigt for at undgå syntaktisk tvetydighed. Et eksempel er:
SELECT 3 OPERATOR(pg_catalog.+) 4;
I praksis er man normalt afhængig af søgestien for operatorer,så man ikke behøver at skrive noget så grimt som det.