OushuDB 建立和管理模式（中）

1、模式搜尋路徑

全稱的名字寫起來非常費勁，并且我們最好不要在應用裡直接寫上特定的模式名。是以， 表通常都是用 位修飾 的名字引用的，這樣的名字裡隻有表名字。 系統通過查找一個 搜尋路徑 來判斷一個表究竟屬于哪個模式， 這個路徑是一個需要查找的模式名清單。在搜尋路徑裡找到的第一個表将被使用。 如果在搜尋路徑中沒有找到表，那麼就報告一個錯誤(即使在資料庫裡的其它模式中存在此表也如此)。

在搜尋路徑中的第一個模式叫做”目前模式”。除了是搜尋的第一個模式之外， 它還是在CREATE TABLE沒有聲明模式名的時候，建立表的預設所在地。

要顯示目前搜尋路徑，使用下面的指令：

SHOW search_path;           

在預設的設定中，傳回:

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

第一個元素聲明搜尋和目前使用者同名的模式。因為還沒有這樣的模式存在，是以這條記錄被忽略。第二個元素指向我們已經看過的public模式。

搜尋路徑中第一個存在的模式是建立新對象的預設位置。這就是為什麼預設的對象都會建立在 public 模式裡的原因。 如果在其它環境中引用對象且沒有模式修飾，那麼系統會周遊搜尋路徑，直到找到一個比對的對象。 是以，在預設的配置裡，任何未修飾的通路隻能引用 public 模式。

要設定模式的搜尋路徑，可以用:

SET search_path TO myschema,public;           

(省略了$user是因為并不立即需要它),然後我們就可以不使用模式修飾來通路表了：

DROP TABLE mytable;           

同樣，因為myschema是路徑中的第一個元素，新對象預設時将建立在這裡。

我們也可以寫成：

SET search_path TO myschema;           

然後我們如果不明确修飾的話，就不能再通路 public 模式了。public 模式沒有任何特殊之處，隻不過它預設時就存在。我們也可以删除它。

搜尋路徑對于資料類型名、函數名、操作符名的運作方式和表名完全相同。 資料類型和函數名可以像表名一樣加以修飾。如果你需要在表達式裡寫一個有模式修飾的操作符， 你必須這麼寫：

OPERATOR(schema.operator)           

這樣是為了避免文法歧義。下面是一個例子：

SELECT 3 OPERATOR(pg_catalog.+) 4;           

實踐中我們通常依賴搜尋路徑尋找操作符，這樣就不用寫這麼難看的東西了。

2、模式和權限

預設時，使用者無法通路模式中不為他們所有的對象。為了讓他們能夠通路，模式的所有者需要在模式上賦予他們USAGE權限。 為了讓使用者使用模式中的對象，我們可能需要賦予該對象适合的額外權限。

使用者也可以在别人的模式裡建立對象。要允許這麼做，需要被賦予在該模式上的CREATE權限。請注意，預設時每個人都在public模式上有CREATE和USAGE權限。 這樣就允許所有可以連接配接到指定資料庫上的使用者在這裡建立對象。如果你不打算這麼做，可以撤銷這個權限：

REVOKE CREATE ON SCHEMA public FROM PUBLIC;           

第一個”public”是模式，第二個”public”意思是”所有使用者”。 第一句裡它是個辨別符，而第二句裡是個關鍵字，是以有不同的大小寫。 記住我們在 辨別符和關鍵詞 裡面說過的原則。

3、系統表模式

除了public和使用者建立的模式之外，每個資料庫都包含一個pg_catalog模式， 它包含系統表和所有内置資料類型、函數、操作符。pg_catalog總是搜尋路徑中的一部分。 如果它沒有明确出現在路徑中，那麼它隐含地在所有路徑 之前 搜尋。 這樣就保證了内置名字總是可以被搜尋。不過，你可以明确地把pg_catalog放在搜尋路徑之後， 如果你想使用使用者自定義的名字覆寫内置的名字的話。

除非必要，你可以在非系統模式裡建立以pg_開頭的表名字。 不過，我們最好還是不要使用這樣的名字，以保證自己将來不會和新版本沖突： 那些版本也許會定義一些和你的表同名的表(在預設搜尋路徑中，一個對你的表的無修飾引用将解析為系統表)。 系統表将繼續遵循以pg_開頭的傳統，是以，隻要你的表不是以pg_開頭， 就不會和無修飾的使用者表名字沖突。