# 10.1\. 概述 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`類型，該類型將在后面描述的晚期階段分析。 在PostgreSQL分析器里， 有四種基本的SQL元素需要獨立的類型轉換規則： 函數調用 多數PostgreSQL類型系統是建筑在一套豐富的函數上的。 函數調用可以有一個或多個參數。因為PostgreSQL允許函數重載， 所以函數名自身并不唯一地標識將要調用的函數， 分析器必須根據函數提供的參數類型選擇正確的函數。 操作符 PostgreSQL允許在表達式上使用前綴或后綴(單目)操作符， 也允許表達式內部使用雙目操作符(兩個參數)。像函數一樣，操作符也可以被重載， 因此操作符的選擇也和函數一樣取決于參數類型。 值存儲 `INSERT`和`UPDATE`語句將表達式結果放入表中。 語句中的表達式類型必須和目標字段的類型一致或者可以轉換為一致。 `UNION`, `CASE`和相關構造 因為聯合`SELECT`語句中的所有查詢結果必須在一列里顯示出來， 所以每個`SELECT`子句中的元素類型必須相互匹配并轉換成一套統一類型。 類似地，一個`CASE`構造的結果表達式必須轉換成統一的類型， 這樣`CASE`表達式自身作為整體有一種已知輸出類型。 同樣的要求也存在于`ARRAY`構造以及`GREATEST`和`LEAST`函數中。 系統表_casts_存儲有關哪種數據類型之間存在哪種轉換以及如何執行這些轉換的信息。 額外的轉換可以由用戶通過[CREATE CAST](#calibre_link-556)命令增加。 這個通常和定義一種新的數據類型一起完成。內置的類型轉換集已經經過仔細的雕琢了， 因此最好不要去更改它們。 分析器中還提供了一個額外的搜索器，允許提高對有隱含轉換的類型組之間的適當的轉換行為的決斷。 數據類型分成了幾個基本_類型分類_，包括：`boolean`, `numeric`, `string`, `bitstring`, `datetime`, `timespan`, `geometric`, `network`, user-defined(用戶定義)。 （參閱列表[Table 47-52](#calibre_link-1465)； 但是要注意的是創建自定義的類型分類也是可能的。） 每種類型都有一種或多種_首選類型_用于解決類型選擇的問題。 小心的選擇首選類型和可用的隱含轉換，就有可能保證有歧義的表達式（那些有多個候選解析方案的） 可以用有效的方式解決。 所有類型轉換規則都是建立在下面幾個基本原則上的： * 隱含轉換決不能有奇怪的或不可預見的輸出。 * 如果一個查詢不需要隱含的類型轉換，分析器或執行器不應該進行更多的額外操作。 這就是說，任何一個類型匹配、格式清晰的查詢不應該在分析器里耗費更多的時間， 也不應該向查詢中引入任何不必要的隱含類型轉換調用。 另外，如果一個查詢通常使用某個函數進行隱含類型轉換，而用戶定義了一個有正確參數的函數， 解釋器應該使用新函數取代原先舊函數的隱含操作。