5.7.3. Ścieżka wyszukiwania schematów
Nazwy kwalifikowane są uciążliwe w pisaniu, a często i tak lepiej nie wprowadzać konkretnych nazw schematów do aplikacji. Dlatego do tabel często odwołujemy się za pomocą nazw niekwalifikowanych, które składają się tylko z nazwy tabeli. System określa, o którą tabelę chodzi poprzez ścieżkę wyszukiwania, która jest listą schematów do przeszukania. Pierwsza pasująca tabela na ścieżce wyszukiwania jest traktowana jako ta poszukiwana. Jeśli nie ma dopasowania w ścieżce wyszukiwania, zgłaszany jest błąd, nawet jeśli pasujące nazwy tabel istnieją w innych schematach w bazie danych.
Możliwość tworzenia obiektów o podobnych nazwach w różnych schematach upraszcza pisanie zapytań, które odwołują się dokładnie do tych samych obiektów za każdym razem. Otwiera to również użytkownikom możliwość zmiany zachowania zapytań innych użytkowników, złośliwie lub przypadkowo. Ze względu na powszechność niewykwalifikowanych nazw w zapytaniach oraz ich użycie we wnętrzach PostgreSQL, dodanie schematu do search_patheffective powoduje, że wszyscy użytkownicy posiadający uprawnienie CREATE mogą korzystać z tego schematu. Kiedy wykonujesz zwykłe zapytanie, złośliwy użytkownik, który może tworzyć obiekty w schemacie Twojej ścieżki wyszukiwania, może przejąć kontrolę i wykonać dowolne funkcje SQL, tak jakbyś to Ty je wykonał.
Pierwszy schemat nazwany w ścieżce wyszukiwania nazywany jest aktualnym schematem. Oprócz tego, że jest to pierwszy przeszukiwany schemat, jest to również schemat, w którym zostaną utworzone nowe tabele, jeśli polecenie CREATE TABLE nie określa nazwy schematu.
Aby wyświetlić bieżącą ścieżkę wyszukiwania, użyj następującego polecenia:
SHOW search_path;
W domyślnej konfiguracji zwraca to:
search_path-------------- "$user",public
Pierwszy element określa, że ma być przeszukiwany schemat o tej samej nazwie co bieżący użytkownik. Jeśli taki schemat nie istnieje, wpis jest ignorowany. Drugi element odnosi się do schematu publicznego, który już widzieliśmy.
Pierwszy schemat na ścieżce wyszukiwania, który istnieje, jest domyślną lokalizacją dla tworzenia nowych obiektów. Jest to powód, dla którego domyślnie obiekty są tworzone w schemacie publicznym. W przypadku odwoływania się do obiektów w jakimkolwiek innym kontekście bez kwalifikacji schematu (modyfikacja tabeli, modyfikacja danych lub polecenia zapytania) ścieżka wyszukiwania jest przesuwana do momentu znalezienia pasującego obiektu. Dlatego w domyślnej konfiguracji, każdy niewykwalifikowany dostęp może ponownie odnosić się tylko do schematu publicznego.
Aby umieścić nasz nowy schemat w ścieżce, użyjemy:
SET search_path TO myschema,public;
(Pomijamy tutaj $user, ponieważ nie jest on nam bezpośrednio potrzebny.Następnie możemy uzyskać dostęp do tabeli bez kwalifikacji schematu:
DROP TABLE mytable;
Ale ponieważ myschema jest pierwszym elementem w ścieżce, nowe obiekty będą domyślnie tworzone init.
Moglibyśmy również napisać:
SET search_path TO myschema;
Wtedy nie mamy już dostępu do publicznego schematu bez jednoznacznej kwalifikacji. Nie ma nic specjalnego w publicznym schemacie poza tym, że istnieje domyślnie. Można go również usunąć.
Patrz również Sekcja 9.25 o innych sposobach manipulowania ścieżką wyszukiwania schematu.
Ścieżka wyszukiwania działa w taki sam sposób dla nazw typów danych, nazw funkcji i nazw operatorów, jak dla nazw tabel. Nazwy typów danych i funkcji mogą być kwalifikowane w dokładnie taki sam sposób jak nazwy tabel. Jeśli musisz napisać kwalifikowaną nazwę operatora w wyrażeniu, istnieje specjalny przepis: musisz napisać
OPERATOR(schema.operator)
Jest to konieczne, aby uniknąć niejednoznaczności składni. Przykładem może być:
SELECT 3 OPERATOR(pg_catalog.+) 4;
W praktyce zwykle polega się na ścieżce wyszukiwania operatorów, aby nie musieć pisać czegoś tak brzydkiego jak to.