第六章. 型態轉換

內容

概述

符號

函數

查詢目標

UNION 查詢

在大多數情況下，用戶不需要明白型態轉換機制的細節。但是，由 Postgres 所進行的隱含的型態轉換會對查詢的結果產生明顯的影響，這些影響又可以由用戶或程式員通過顯式的型態轉換進行剪裁利用。

本章介紹 Postgres 型態轉換的傳統和機制。關於特定的型態和函數及符號的進一步資訊，請參考用戶手冊和程式員手冊有關章節。

在程式員手冊裡有關於隱含型態轉換的具體算法的更詳細的介紹。

概述

Postgres 掃描/分析器只將語法元素分解成五個基本種類：整數（integers），浮點數（floats）， 字符串（strings），名字（names）和關鍵字（keywords）。大多數擴展的型態首先表征為字符串（strings）。SQL 語言的定義允許將型態名聲明為字符串，這個機制被Postgres 用於令分析器沿著正確的方向運行。例如，下面查詢

tgl=> SELECT text 'Origin' AS "Label", point '(0,0)' AS "Value";
 Label  | Value
--------+-------
 Origin | (0,0)
(1 row)

在 Postgres 分析器裡，有四種基本的 SQL 元素需要獨立的型態轉換規則：

符號

Postgres 允許表達式裡使用雙目符號（兩個參數），也允許使用左目或右目符號（單目符號，一個參數）。

函數調用

多數 Postgres 型態系統是建筑在一套豐富的函數上的。任何查詢中調用的函數的參數，不管是一個還是多個，必須符合該函數在系統表裡的定義。

查詢目標

SQL INSERT 語句將查詢結果插入表中。查詢表達式的型態必須和insert語句的目標列一致或者是（可能需要）轉換成一致的。

聯合(UNION)查詢

因為 UNION SELECT 語句的所有查詢結果必須在一列裡顯示出來，所以每個 SELECT  子句中的元素型態必須相互匹配並轉換成一套統一型態。

Postgres 分析器的習慣是：所有型態轉換函數接受一個型態是源型態的參數，該參數與目標型態同名。任何符合這一標準的函數都被認為是一個有效的轉換函數，因而可以被分析器當作轉換函數使用。這個簡單的假設令分析器在不需要寫硬程式碼的基礎上就可以充分利用型態轉換的能力，也讓用戶定義的型態可以透明地使用同一特性。

分析器中還有一個搜索器用於更好地猜測 SQL 標準型態的確切特性。分析器裡有五種定義的型態：布爾（boolean），字符串（string），數字（numeric），幾何（geometric）和用戶定義（user-defined）。 除用戶定義型態外，每種型態都有一種"優選型態"用於解決型態定義不明確的問題。每一個"用戶定義"的型態就是其自身的"優選型態"，所以那些含混不清的表達式（在分析結果中有多種可能的表達式） 如果只有一個用戶定義型態則可以正確分析，而那些有多個用戶定義型態的表達式會仍然是含糊的，因而會拋出分析錯。

含糊的表達式如果其多種候選可能性都是同一種數據型態，則有可能被正確分析，而如果其候選可能性是幾種數據型態，則分析很可能會報錯，並要求用戶將表達式明確化。

要決

• 隱含轉換決不能有奇怪的或不可預見的輸出。
• 用戶定義型態，因為分析器對其沒有預先的認識，在型態級別中應該級別較"高"。在混合型態的表達式裡，內部型態總是應該轉換成用戶定義型態。（當然只是在必須轉換的時候）。
• 用戶定義型態是不相關的。當前，Postgres 除了用於內部數據型態的硬程式碼搜索器和以系統表中現有函數為基礎的隱含型態關系外，沒有任何可用於處理型態間關系的資訊。
• 如果一個查詢不需要隱含的型態轉換，分析器或執行器不應該進行更多的額外操作。這就是說，任何一個型態匹配，格式清晰的查詢不應該在分析器裡耗費更多的時間，也不應該做任何不必要的型態轉換。


另外，如果一個查詢通常使用某個函數進行隱含型態轉換，而用戶顯式定義了一個有正確參數的函數，解釋器應該使用新函數取代原先舊函數的隱含操作。