5.7.3. スキーマ検索パス
修飾名は書くのが面倒ですし、アプリケーションに特定のスキーマ名を使用しない方が良い場合もあります。 そのため、テーブルはしばしば非限定名で参照され、それはテーブル名だけで構成されています。 システムは、検索パス（検索するスキーマのリスト）をたどることによって、どのテーブルを意味するかを決定します。 検索パスに一致するテーブルがない場合、データベース内の他のスキーマに一致するテーブル名が存在する場合でも、エラーが報告されます。
異なるスキーマで同じ名前のオブジェクトを作成する機能は、毎回正確に同じオブジェクトを参照するクエリを書くことを複雑にしています。 また、悪意を持って、または偶然に、ユーザーが他のユーザーのクエリの動作を変更する可能性も出てきます。 PostgreSQL内部では修飾されていない名前が広く使われているため、search_patheにスキーマを追加すると、そのスキーマのCREATE権限を持つ全てのユーザを事実上信頼することになります。 通常のクエリを実行すると、searchpath のスキーマにオブジェクトを作成できる悪意のあるユーザが制御権を持ち、あたかも自分が実行したかのように任意の SQL 関数を実行することができます。
現在の検索パスを表示するには、次のコマンドを使用します。
SHOW search_path;
デフォルトの設定では、次のように返されます。 そのようなスキーマが存在しない場合、このエントリは無視されます。 2 番目の要素は、すでに見てきたパブリック スキーマを参照します。
存在する検索パスの最初のスキーマは、新しいオブジェクトを作成するための既定の場所です。 それが、デフォルトでオブジェクトがパブリック・スキーマで作成される理由です。 オブジェクトがスキーマの修飾なしに他のコンテキストで参照される場合（テーブルの変更、データの変更、またはクエリーコマンド）、検索パスは一致するオブジェクトが見つかるまで走査されます。
新しいスキーマをパスに入れるには、次のように使用します：
SET search_path TO myschema,public;
(ここでは、すぐに必要ではないので $user を省略しています。
DROP TABLE mytable;
また、myschema はパスの最初の要素であるため、新しいオブジェクトはデフォルトで init.
と記述することもできます。 publicschemaについては、デフォルトで存在すること以外、特別なことは何もありません。
スキーマ検索パスを操作する他の方法については、セクション9.25も参照してください。 データ型名および関数名は、テーブル名とまったく同じ方法で修飾することができます。 式の中で修飾された演算子名を記述する必要がある場合は、特別な規定があります：
OPERATOR(schema.operator)
これは構文のあいまいさを避けるために必要です。 例としては、
SELECT 3 OPERATOR(pg_catalog.+) 4;
実際には、演算子の検索パスに依存することが多く、そのような醜いものを書かなくても済むようにします。