概述

SQL是強類型語言。也就是說，每個數(shù)據(jù)都與一個決定其行為和用法的數(shù)據(jù)類型相關聯(lián)。OushuDB 有一個可擴展的數(shù)據(jù)類型系統(tǒng)， 該系統(tǒng)比其它SQL實現(xiàn)更具通用性和靈活性。因此，OushuDB 中大多數(shù)類型轉換是由通用規(guī)則來管理的， 而不是由專門的試探法分析的，這種做法允許使用混合類型的表達式， 即便是其中包含用戶定義的類型也如此。

OushuDB 掃描/分析器只將詞法元素分解成五個基本種類： 整數(shù)、浮點數(shù)、字符串、標識符、關鍵字。大多數(shù)非數(shù)字類型首先表征為字符串，SQL 語言定義允許聲明字符串的類型名，而且這種機制可以用于OushuDB 保證分析器沿著正確的方向運行。例如，查詢：

SELECT text 'Origin' AS "label", point '(0,0)' AS "value";label | value--------+-------Origin | (0,0)(1 row)

有兩個文本常量，類型分別為text和point。 如果沒有為字符串文本聲明類型，該文本先被初始化成一個擁有存儲空間的 unknown類型，該類型將在后面描述的晚期階段分析。

在OushuDB 分析器里， 有四種基本的SQL元素需要獨立的類型轉換規(guī)則：

函數(shù)調用

多數(shù)OushuDB 類型系統(tǒng)是建立在一套豐富的函數(shù)上的。函數(shù)調用可以有一個或多個參數(shù)。因為OushuDB 允許函數(shù)重載， 所以函數(shù)名自身并不唯一地標識將要調用的函數(shù)， 分析器必須根據(jù)函數(shù)提供的參數(shù)類型選擇正確的函數(shù)。

操作符

OushuDB 允許在表達式上使用前綴或后綴(單目)操作符， 也允許表達式內部使用雙目操作符(兩個參數(shù))。像函數(shù)一樣，操作符也可以被重載， 因此操作符的選擇也和函數(shù)一樣取決于參數(shù)類型。

值存儲

INSERT和UPDATE語句將表達式結果放入表中。 語句中的表達式類型必須和目標列的類型一致或者可以轉換為一致。

UNION, CASE和相關構造

因為聯(lián)合SELECT語句中的所有查詢結果必須在一列里顯示出來， 所以每個SELECT子句中的元素類型必須相互匹配并轉換成一套統(tǒng)一類型。 類似地，一個CASE構造的結果表達式必須轉換成統(tǒng)一的類型， 這樣CASE表達式自身作為整體有一種已知輸出類型。 同樣的要求也存在于ARRAY構造中。

系統(tǒng)表casts存儲有關哪種數(shù)據(jù)類型之間存在哪種轉換以及如何執(zhí)行這些轉換的信息。額外的轉換可以由用戶通過CREATE CAST命令增加。(這個通常和定義一種新的數(shù)據(jù)類型一起完成。內置的類型轉換集已經經過仔細的雕琢了， 因此最好不要去更改它們。)

分析器中還提供了一個額外的搜索器，允許提高對有隱含轉換的類型組之間的適當?shù)霓D換行為的決斷。數(shù)據(jù)類型分成了幾個基本 類型分類 ，包括：boolean, numeric, string, bitstring, datetime, timespan, geometric, network, user-defined(用戶定義)。每種類型(除用戶定義)都有一種或多種 首選類型 用于解決類型選擇的問題。因此歧義的表達式（那些有多個候選解析方案的）當有多個內置類型時可以解決，但是用戶定義的類型有多個選擇時會產生錯誤。

所有類型轉換規(guī)則都是建立在下面幾個基本原則上的：

• 隱含轉換決不能有奇怪的或不可預見的輸出。

• 解析器沒有 先驗 知識的用戶定義類型應該是 “較高的” 類型等級。在混合類型表達式中，本地類型總應該轉換為用戶定義的類型(當然，只要轉換是必要的)。

• 用戶定義的類型是不相關的?，F(xiàn)在，除了內置類型的硬編碼啟發(fā)式和可用函數(shù)和轉換的隱式關系外，OushuDB 沒有類型之間關系的可用信息。

• 如果一個查詢不需要隱含的類型轉換，分析器或執(zhí)行器不應該進行更多的額外操作。 這就是說，任何一個類型匹配、格式清晰的查詢不應該在分析器里耗費更多的時間， 也不應該向查詢中引入任何不必要的隱含類型轉換調用。

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