# CREATE CAST ## Name CREATE CAST?--?定義一個用戶定義的轉換 ## Synopsis ``` CREATE CAST (_source_type_ AS _target_type_) WITH FUNCTION _function_name_ (_argument_type_ [, ...]) [ AS ASSIGNMENT | AS IMPLICIT ] CREATE CAST (_source_type_ AS _target_type_) WITHOUT FUNCTION [ AS ASSIGNMENT | AS IMPLICIT ] CREATE CAST (_source_type_ AS _target_type_) WITH INOUT [ AS ASSIGNMENT | AS IMPLICIT ] ``` ## 描述 `CREATE CAST`定義一個新的轉換。一個轉換說明如何在兩個類型之間進行轉換。比如： ``` SELECT CAST(42 AS float8); ``` 通過調用前面指定的函數將整數常量42轉化為`float8`類型，即`float8(int4)`的形式。 （如果沒有定義合適的轉換, 轉換將失敗。） 兩種形式是二進制可強制轉換的，這意味轉換可以在不調用函數的情況下自由執行。 這要求相應的值使用相同的內部表示。例如，`text`和`varchar`形式都是二進制可強制轉換的兩種類型。 二進制可可強制轉換未必是一個對稱的關系。例如： `xml`到text的轉換可以在當前的處理中可直接執行。 但相反的方向的轉換需要一個函數來執行，至少一個語法檢查。（兩種二進制可強制轉換的形式也被稱為二進制兼容。） 您可以定義一個轉換為使用`WITH INOUT`語法的_I/O conversion cast_轉化轉換。 一個I/O轉化轉換通過調用原數據庫類型的輸出函數來執行，并將結果傳給目標數據類型的輸入函數。 缺省時，只有在明確要求轉換的情況下才調用一個轉換，也就是一個明確的`CAST(``_x_` AS `_typename_`)或`_x_``::``_typename_`轉換要求。 如果轉換被標記為`AS ASSIGNMENT`，那么在給目標數據類型的字段賦值的時候，可以隱含調用它。 比如，假設`foo.f1`是一個類型為`text`的字段， 那么： ``` INSERT INTO foo (f1) VALUES (42); ``` 如果從`integer`類型到`text`類型的轉換標記為`AS ASSIGNMENT`，上面的這句就被允許，否則就不允許。 （通常用術語_assignment cast_來描述這種轉換。） 如果轉換標記了`AS IMPLICIT`，那么可以在任何環境下調用，不管是作業還是在一個內部表達式中。 （我們通常使用術語_implicit cast_來描述這種轉換。 ） 例如，考慮下面這個查詢： ``` SELECT 2 + 4.0; ``` 解析器初始時標記常量分別為`integer`和`numeric`。 在系統目錄中沒有`integer` + `numeric`的操作符， 但是有一個`integer` + `numeric`操作符。 若`integer`到`numeric`的轉換是可以執行的并且標記為 `AS IMPLICIT` — 則該查詢將會成功執行。 解析器將使用隱性的轉換并按所寫的查詢生成結果： ``` SELECT CAST ( 2 AS numeric ) + 4.0; ``` 現在，目錄提供了一個從`numeric`到`integer`的轉換。 如果那個轉換標記了`AS IMPLICIT` —而它并不是— 然后解析器會面臨對選擇上面的解釋還是選擇`numeric`常量到`integer`的轉換， 然后應用`integer` `+` `integer`操作符。 缺乏選擇哪一種處理方式的足夠信息，系統會放棄執行并返回查詢是模棱兩可的信息。 兩種轉換中僅有一個是缺省的方式正是我們設計的方式，我們讓解析器更偏向于將`numeric`-和-`integer`的混合表達式的結果視作`numeric`； 沒有關于那方面的內置信息。 在是否將轉換標記為隱性的問題上保守一些是明智的。 過于豐富的隱含轉換路徑 會導致PostgreSQL選擇讓人奇怪的命令解析，或者是完全不能解析命令，因為存在多個可能的解析。 一個好的規則是，只有在同一個通用類型范疇里面的那些可以保留轉換信息的類型之間才標記為可隱含調用轉換。 比如，從`int2`到`int4`可以合理地標記為隱含轉換，但是從`float8`到`int4`也許應該標記為賦值轉換。 跨類型范圍的轉換，比如`text`到`int4`，只能明確地轉換。 > **Note:** 有時，有必要為了可用性和標準支持的原因在一組類型中提供多個隱含轉換，導致上述無法避免的模棱兩可的問題。 解析器有一個基于_type categories_和_preferred types_的啟發式函數回調功能，有助于在這種情況下提供所期望的行為。 參閱[CREATE TYPE](#calibre_link-100)獲取更多詳細信息。 為了能夠創建一個轉換，您必須是源或者目標數據類型的所有者。 為了創建一個強制二進制的轉換，您必須是超級用戶。 （做這個約束的原因是錯誤的二進制可強迫轉換轉換可以很容易讓服務器崩潰。） ## 參數 `_source_type_` 轉換的源數據類型。 `_target_type_` 轉換的目標數據類型。 `_function_name_`(`_argument_type_` [, ...]) 用于執行轉換的函數。 這個函數名可以是用模式名修飾的。 如果它沒有用模式名修飾， 那么該函數將從模式搜索路徑中找出來。 函數的結果數據類型必須匹配轉換的目標類型。 它的參數在下面討論。 `WITHOUT FUNCTION` 表明源類型是對目標類型是二進制可強制轉換的，所以沒有函數需要執行此轉換。 `WITH INOUT` 表明轉換是I/O轉換，通過調用源數據類型的輸出函數來執行，并將結果傳給目標數據類型的輸入函數。 `AS ASSIGNMENT` 表示轉換可以在賦值模式下隱含調用。 `AS IMPLICIT` 表示轉換可以在任何環境里隱含調用。 轉換實現函數可以有一到三個參數。 第一個參數的類型必須與轉換的源類型相同的，或可以從轉換的源類型二進制可強制轉換的。 第二個參數，如果存在，必須是`integer`類型；它接收這些與目標類型相關聯的類型修飾符，或者若什么都沒有則是-1。 第三個參數，如果存在，必須是`boolean`類型；若轉換是一個顯式類型轉換則會收到`true`，否則是`false`。 （奇怪的是，在一些情況下SQL標準要求對顯式和隱式轉換的不同表現。我們不推薦您設計自己的數據類型，這很重要。） 一個轉換函數的返回類型必須是與轉換的目標類型相同或者對轉換的目標類型二進制可強制轉換 。 通常，一個轉換必須有不同的源和目標數據類型。 然而，若有多于一個參數的轉換實現函數，則允許聲明一個有相同的源和目標類型的轉換。 這用于表示系統目錄中的特定類型的長度強制函數。 命名的函數用于強制一個該類型的值為第二個參數給出的類型修飾符值。 如果一個類型轉換的源類型和目標類型不同，并且接收多于一個參數，它就表示從一種類型轉換成另外一種類型只用一個步驟，并且同時實施長度轉換。 如果沒有這樣的項可用， 那么轉換成一個使用了類型修飾詞的類型將涉及兩個步驟，一個是在數據類型之間轉換， 另外一個是施加修飾詞指定的轉換。 對域類型的轉換目前沒有作用。轉換一般是針對域相關的所屬數據類型。 ## 注意 使用[DROP CAST](#calibre_link-535)刪除用戶定義的轉換。 請注意，如果希望能雙向轉換類型，那么你需要明確地定義兩個方向的轉換。 通常不需要創建用戶定義類型與標準字符串類型之間的轉換(`text`，`varchar`和`char(``_n_`)，以及被定義為字符串的范疇的用戶定義的類型)。 PostgreSQL為此提供自動I/O轉換轉換。 字符串類型的自動轉換可以認為是分配轉換，而來自字符串的自動轉換是唯一顯式的。 您可以通過聲明自己的轉換替換系統的自動轉換，但是，通常這么做的唯一原因是，你想讓轉化比標準唯一分配或者唯一顯式設置更容易調用。 另一個可能的原因是你想讓轉化變現的不同于類型的I/O函數； 但是最重要的是您應該反復考慮這是否是一個好主意。（少量內部類型確實對轉換有不同的性能要求，大部分是因為要求SQL標準。） 在PostgreSQL7.3之前，每個與數據類型名稱相同的函數會返回那個數據類型，并取一個不同類型的參數的函數，自動成為一個轉換函數。 在面臨模式引入時約定已取消并且能代表系統表中的二進制可強制轉換。內置的轉換功能仍然遵循這種命名模式，但是他們必須像系統表`pg_cast`中的轉換一樣顯示。 雖然不是必須的，但是還是建議你遵循舊的命名類型轉換實現函數的習慣，也就是說， 函數名和目標數據類型同名。 許多用戶習慣于使用函數風格的表示法`_typename_`(`_x_`)來做數據類型轉換。 這種表示法恰好就是調用類型轉換實現函數，這樣并不會被當作一種類型轉換而被特殊看待。 如果你的轉換函數沒有按照這種傳統命名，那么你就會讓用戶很奇怪。 因為PostgreSQL允許同名不同參數的函數重載，因此同時存在多個從不同類型向同樣類型轉換的同名轉換函數一點問題都沒有。 > **Note:** 事實上前面所述是過分簡化的：在兩種情況下函數調用結構被認為是一個轉換請求而不需要將其匹配為一個實際函數。 如果函數調用`_name_`(`_x_`)不準確匹配任何現有函數，但是`_name_`是一個數據類型的名稱 并且`pg_cast`從`_x_`類型提供了一個二進制可強制轉換到這個類型，則調用會被解析為一個二進制可強制轉換。 即使是沒有任何轉換函數，也設計了一種異常，二進制可強制轉換可以通過使用函數語法來調用， 同樣的，若無`pg_cast`條目，但轉換會到達或者來自一個字符串類型， 調用將會被視為一個I/O轉換轉換。 該異常情況下允許I/O轉換轉換通過使用函數語法來調用。 > **Note:** 也還有一種異常中的異常：從復合數據類型向字符串類型的I/O轉換不能使用函數語法，必須設計為精確的轉換語法（`CAST` 或 `::` 聲明） 增加這種異常是因為在介紹過自動執行的I/O轉換后，用戶會發現在一個函數或是字段參考時很容易誤執行一個類似的轉換。 ## 例子 為了從類型`bigint`到類型`int4`創建一個指派映射要通過使用函數`int4(bigint)`: ``` CREATE CAST (bigint AS int4) WITH FUNCTION int4(bigint) AS ASSIGNMENT; ``` （這個轉換在系統中已經預先定義了。） ## 兼容性 `CREATE CAST`指令符合SQL標準，除了SQL沒有為二進制可強制轉換類型或者實現函數的額外參數來實現功能。 `AS IMPLICIT`也是一個PostgreSQL擴展。 ## 參見 [CREATE FUNCTION](#calibre_link-4)、[CREATE TYPE](#calibre_link-100) 和[DROP CAST](#calibre_link-535)