SQL是一種強型別語言。也就是說,每個資料項目都具有相關的資料類型,該資料類型決定了其行為和允許的使用方式。PostgreSQL 具有可擴展的類型系統,該系統比其他系統更通用和更靈活SQL實作方式。因此,PostgreSQL 中的大多數類型轉換行為都受通用規則的約束,而不是受特定的啟發式方法的約束。這允許即使使用使用者定義的類型也可以使用混合類型運算式。
PostgreSQL 掃描器/剖析器將詞法元素分為五個基本類別:整數、非整數數字、字串、識別碼和關鍵字。大多數非數值類型的常數首先被歸類為字串。該SQL語言定義允許使用字串指定類型名稱,並且此機制可用於 PostgreSQL 中,以啟動剖析器沿正確的路徑向下執行。例如,查詢
SELECT text 'Origin' AS "label", point '(0,0)' AS "value"; label | value --------+------- Origin | (0,0) (1 row)
具有兩個常值常數,分別為 text
類型和 point
類型。如果未為字串常值指定類型,則最初會分配預留位置類型 unknown
,以便在稍後的階段中解決,如下所述。
有四個基本SQL在 PostgreSQL 剖析器中需要不同的類型轉換規則的建構
大部分的 PostgreSQL 類型系統都建立在一組豐富的函式之上。函式可以有一個或多個引數。由於 PostgreSQL 允許函式多載,因此僅函式名稱並不能唯一地識別要呼叫的函式;剖析器必須根據提供的引數的資料類型選擇正確的函式。
PostgreSQL 允許使用前置(單一引數)運算子以及中置(雙引數)運算子的運算式。與函式一樣,運算子可以多載,因此存在選擇正確運算子的相同問題。
SQL INSERT
和 UPDATE
陳述式將運算式的結果放入資料表中。陳述式中的運算式必須與目標欄位的類型匹配,並且可能需要轉換為目標欄位的類型。
UNION
、CASE
和相關的建構由於來自聯合 SELECT
陳述式的所有查詢結果都必須顯示在一組欄位中,因此每個 SELECT
子句的結果類型必須匹配並轉換為統一的集合。同樣,CASE
建構的結果運算式必須轉換為通用類型,以便 CASE
運算式整體具有已知的輸出類型。某些其他建構(例如 ARRAY[]
以及 GREATEST
和 LEAST
函式)同樣需要確定多個子運算式的通用類型。
系統目錄儲存有關哪些轉換或類型轉換存在於哪些資料類型之間,以及如何執行這些轉換的資訊。使用者可以使用 CREATE CAST 命令新增其他類型轉換。(這通常與定義新的資料類型結合使用。內建類型之間的類型轉換集經過仔細設計,最好不要更改。)
剖析器提供的其他啟發式方法允許改進對具有隱含類型轉換的類型組之間正確類型轉換行為的確定。資料類型分為幾個基本類型類別,包括 boolean
、numeric
、string
、bitstring
、datetime
、timespan
、geometric
、network
和使用者定義。(有關清單,請參閱 表 51.65;但請注意,也可以建立自訂類型類別。)在每個類別中,可以有一個或多個慣用類型,當有多種可能的類型可供選擇時,慣用類型會優先使用。透過仔細選擇慣用類型和可用的隱含類型轉換,可以確保以有用的方式解析不明確的運算式(具有多個候選剖析解決方案的運算式)。
所有類型轉換規則的設計都考慮到以下幾個原則
隱含類型轉換不應有令人驚訝或無法預測的結果。
如果查詢不需要隱含類型轉換,則剖析器或執行器中不應有額外的負擔。也就是說,如果查詢格式正確且類型已匹配,則查詢應執行,而無需在剖析器中花費額外時間,並且無需在查詢中引入不必要的隱含轉換呼叫。
此外,如果查詢通常需要對函式進行隱含轉換,並且如果使用者隨後定義了具有正確引數類型的新函式,則剖析器應使用此新函式,並且不再進行隱含轉換以使用舊函式。
如果您在文件中發現任何不正確、與您使用特定功能的經驗不符或需要進一步澄清的地方,請使用此表單來報告文件問題。