xml
資料型別可用於儲存 XML 資料。與在 text
欄位中儲存 XML 資料相比,它的優點在於它會檢查輸入值的格式是否正確,並且支援函式來執行型別安全的對該資料的操作;參見 第 9.15 節。使用此資料型別需要安裝時已使用 configure --with-libxml
進行構建。
xml
型別可以儲存格式正確的 XML 標準所定義的“文件”,以及“內容”片段,後者是根據 XQuery 和 XPath 資料模型的“文件節點”的更寬鬆的定義來定義的。大致來說,這意味著內容片段可以有多個頂級元素或字元節點。表示式
可用於判斷某個 xmlvalue
IS DOCUMENTxml
值是否為完整文件或僅為內容片段。
有關 xml
資料型別的限制和相容性說明,請參見 第 D.3 節。
要從字元資料生成 xml
型別的值,請使用 xmlparse
函式:
XMLPARSE ( { DOCUMENT | CONTENT } value
)
示例
XMLPARSE (DOCUMENT '<?xml version="1.0"?><book><title>Manual</title><chapter>...</chapter></book>') XMLPARSE (CONTENT 'abc<foo>bar</foo><bar>foo</bar>')
雖然根據 SQL 標準,這是將字元字串轉換為 XML 值的唯一方法,但 PostgreSQL 特有的語法
xml '<foo>bar</foo>' '<foo>bar</foo>'::xml
也可使用。
xml
型別不驗證輸入值是否符合文件型別宣告 (DTD), 即使輸入值指定了 DTD。目前也不支援對 XML Schema 等其他 XML 模式語言進行驗證。
反向操作,即從 xml
生成字元字串值,使用的是 xmlserialize
函式:
XMLSERIALIZE ( { DOCUMENT | CONTENT }value
AStype
[ [ NO ] INDENT ] )
type
可以是 character
、character varying
或 text
(或其中之一的別名)。同樣,根據 SQL 標準,這是在 xml
型別和字元型別之間進行轉換的唯一方法,但 PostgreSQL 也允許您直接進行型別轉換。
INDENT
選項會使結果進行美化列印,而 NO INDENT
(這是預設值)僅輸出原始輸入字串。轉換為字元型別同樣會產生原始字串。
當字元字串值在不經過 XMLPARSE
或 XMLSERIALIZE
的情況下轉換為 xml
型別或從 xml
型別轉換時,DOCUMENT
或 CONTENT
的選擇由 “XML 選項” 會話配置引數決定,該引數可以使用標準命令進行設定
SET XML OPTION { DOCUMENT | CONTENT };
或更 PostgreSQL 風格的語法
SET xmloption TO { DOCUMENT | CONTENT };
預設值為 CONTENT
,因此允許所有形式的 XML 資料。
在處理客戶端、伺服器和透過它們傳遞的 XML 資料中的多種字元編碼時,必須小心。當使用文字模式將查詢傳遞給伺服器並將查詢結果傳遞給客戶端(這是正常模式)時,PostgreSQL 會在客戶端和伺服器之間轉換所有字元資料,並將其轉換為各自端的字元編碼;參見 第 23.3 節。這包括 XML 值的字串表示形式,如前面的示例所示。這通常意味著 XML 資料中包含的編碼宣告可能會失效,因為字元資料在客戶端和伺服器之間傳輸時會被轉換為其他編碼,而嵌入的編碼宣告不會被更改。為了應對這種行為,傳遞給 xml
型別輸入的字元字串中包含的編碼宣告將被 忽略,並假定內容採用當前的伺服器編碼。因此,為了正確處理,XML 資料的字元字串必須以當前的客戶端編碼從客戶端傳送。由客戶端負責在傳送到伺服器之前將文件轉換為當前客戶端編碼,或適當地調整客戶端編碼。在輸出時,xml
型別的值不會有編碼宣告,客戶端應假定所有資料都採用當前的客戶端編碼。
當使用二進位制模式將查詢引數傳遞給伺服器並將查詢結果返回給客戶端時,不會執行編碼轉換,因此情況有所不同。在這種情況下,會識別 XML 資料中的編碼宣告,如果缺失,則假定資料採用 UTF-8(根據 XML 標準的要求;請注意 PostgreSQL 不支援 UTF-16)。在輸出時,資料將包含一個指定客戶端編碼的編碼宣告,除非客戶端編碼是 UTF-8,在這種情況下將省略。
Needless to say, processing XML data with PostgreSQL will be less error-prone and more efficient if the XML data encoding, client encoding, and server encoding are the same. Since XML data is internally processed in UTF-8, computations will be most efficient if the server encoding is also UTF-8.
當伺服器編碼不是 UTF-8 時,某些與 XML 相關的函式可能根本無法處理非 ASCII 資料。已知 xmltable()
和 xpath()
函式尤其存在這個問題。
xml
資料型別比較特殊,因為它不提供任何比較運算子。這是因為 XML 資料沒有明確定義且普遍有用的比較演算法。其後果之一是您無法透過比較 xml
列和搜尋值來檢索行。因此,XML 值通常應附帶一個單獨的鍵欄位,例如 ID。比較 XML 值的替代解決方案是先將其轉換為字元字串,但請注意,字元字串比較與有用的 XML 比較方法幾乎無關。
由於 xml
資料型別沒有比較運算子,因此無法直接在具有該型別的列上建立索引。如果需要對 XML 資料進行快速搜尋,可能的解決方法包括將表示式強制轉換為字元字串型別並對其進行索引,或索引 XPath 表示式。當然,實際的查詢必須調整為按索引表示式進行搜尋。
PostgreSQL 中的文字搜尋功能也可用於加快 XML 資料的全文搜尋。但是,PostgreSQL 分發版中尚未提供必要的預處理支援。
如果您在文件中發現任何不正確、與您在使用特定功能時的經驗不符或需要進一步澄清的內容,請使用 此表單 報告文件問題。