5.7.3. Calea de căutare a schemelor
Numele calificate sunt plictisitoare de scris și, oricum, de multe ori este mai bine să nu se introducă un anumit nume de schemă în aplicații. Prin urmare, tabelele sunt adesea menționate prin nume necalificate, care constau doar din numele tabelului. Sistemul determină la ce tabel se referă urmărind o cale de căutare, care este o listă de scheme în care trebuie să se caute.Se consideră că primul tabel care corespunde în calea de căutare este cel dorit. Dacă nu există nici o potrivire în calea de căutare, se raportează o eroare, chiar dacă există nume de tabele corespunzătoare în alte scheme din baza de date.
Capacitatea de a crea obiecte cu nume similare în scheme diferite complică scrierea unei interogări care să facă referire exact la aceleași obiecte de fiecare dată. De asemenea, deschide posibilitatea ca utilizatorii să schimbe comportamentul interogărilor altor utilizatori, în mod rău intenționat sau accidental. Din cauza prevalenței numelor necalificate în interogări ș i a utilizării lor în PostgreSQLinternals, adăugarea unei scheme la search_patheffectively conferă încredere tuturor utilizatorilor care au CREATEprivilege pe schema respectivă. Atunci când executați o interogare obișnuită, un utilizator rău intenționat capabil să creeze obiecte într-o schemă din calea de căutare poate prelua controlul și să execute funcții SQL arbitrare ca și cum le-ați fi executat dumneavoastră.
Prima schemă numită în calea de căutare se numește schema curentă (currentschema). Pe lângă faptul că este prima schemă căutată, aceasta este, de asemenea, schema în care vor fi create noile tabele dacă comanda CREATE TABLE nu specifică un nume de schemă.
Pentru a afișa calea de căutare curentă, utilizați următoarea comandă:
SHOW search_path;
În configurația implicită, aceasta returnează:
search_path-------------- "$user",public
Primul element specifică faptul că trebuie căutată o schemă cu același nume cu cel al utilizatorului curent. Dacă nu există o astfel de schemă, elementul este ignorat. Al doilea element se referă la schema publică pe care am văzut-o deja.
Prima schemă din calea de căutare care există este locația implicită pentru crearea de noi obiecte. Acesta este motivul pentru care obiectele bydefault sunt create în schema publică. Atunci când se face referire la obiecte în orice alt context fără calificare de schemă (modificarea tabelelor, modificarea datelor sau comenzi de interogare), calea de căutare este parcursă până când se găsește un obiect corespunzător. Prin urmare, în configurația implicită, orice acces necalificat se poate referi din nou numai la schema publică.
Pentru a pune noua noastră schemă în calea de căutare, folosim:
SET search_path TO myschema,public;
(Omitem $user aici pentru că nu avem nevoie imediată de el.) Și apoi putem accesa tabelul fără calificare de schemă:
DROP TABLE mytable;
De asemenea, din moment ce myschema este primul element din cale, noile obiecte vor fi create în mod implicit init.
Am fi putut de asemenea să scriem:
SET search_path TO myschema;
Apoi nu mai avem acces la schema publică fără calificare explicită. Nu există nimic special în legătură cu schema publică, cu excepția faptului că ea există în mod implicit. Ea poate fi eliminată,de asemenea.
Vezi, de asemenea, secțiunea 9.25 pentru alte moduri de a manipula calea de căutare a schemei.
Calea de căutare funcționează în același mod pentru numele tipurilor de date, numele funcțiilor și numele operatorilor ca și pentru numele tabelelor. Numele tipurilor de date și ale funcțiilor pot fi calificate exact în același mod ca și numele tabelelor. Dacă trebuie să scrieți un nume de operator calificat într-o expresie, există o dispoziție specială: trebuie să scrieți
OPERATOR(schema.operator)
Acest lucru este necesar pentru a evita ambiguitatea sintactică. Un exemplu este:
SELECT 3 OPERATOR(pg_catalog.+) 4;
În practică se apelează de obicei la calea de căutare pentru operatori,pentru a nu fi nevoit să scrie ceva atât de urât ca acesta.