2.7 SQL中的类型检查和型转
SQL只支持弱形式的强类型化（如果你明白我的意思的话）。具体说包括：
- BOOLEAN值只能赋值到BOOLEAN变量，并只能和BOOLEAN值比较。
- 数字值只能赋值给数值变量，并且只能与数字值比较（此处的“数字”（numeric）指的是SMALLINT、BIGINT、NUMERIC、DECIMAL 或者FLOAT ）。
- 字符串值只能赋值给字符串变量并且只能与字符串值进行比较（此处的“字符串”指的是CHAR、VARCHAR或者CLOB）
- 位串值只能赋值给位串变量并且只能和位串值比较（这里的“位串”指的是BINARY 、BINARY VARYING或BLOB ）
因此，像数值与字符串这样的比较就是非法的。然而，即使两个数的类型不同，它们之间的比较也是合法的，比如分别属于INTEGER和FLOAT类型的两个数（此时，整型值会在进行比较之前强制型转为FLOAT类型）。这就涉及类型型转问题。在通常的计算领域中，一个广为认可的原则就是要尽量避免型转，因为它们容易出错。尤其是在SQL中，允许型转的一个怪异后果就是某些集合并、交、差运算会产生一些在任何运算元中都没有出现过的行！比如，考虑图2.3中的SQL表T1和T2。假设T1中的X列为INTEGER型，T2表中的X列为NUMERIC(5,1)类型；T1中的Y列为NUMERIC (5,1)类型；T2表中的Y列为INTEGER类型。现在，考虑下面的SQL查询：
SELECT X , Y FROM T1
UNION
SELECT X , Y FROM T2
结果显示在图2.3的最右侧：结果中的X列和Y列都是NUMERIC（5,1）类型，且这些列中的值实际上都由INTEGER型转为NUMERIC（5,1）类型。因此，结果是由未在T1和T2表中出现的行组成的——非常奇怪的并，你要是这么想的话是可以理解的。注17
图2.3：很奇怪的“并”
强烈建议：只要可能就尽量避免型转。（我自己的习惯是：无论是在SQL还是其他上下文中，都完全不用它们。）尤其是在SQL上下文中，要确保同名列始终具有同一类型；这个规则以及本书中其他建议，目的是确保能基本避免类型转换。当类型转换无法避免时，建议使用CAST或CAST的等价物进行显式类型转换。比如（对于前述的UNION查询）：
SELECT CAST ( X AS NUMERIC(5,1) ) AS X , Y FROM T1
UNION
SELECT X , CAST ( Y AS NUMERIC(5,1) ) AS Y FROM T2
然而,为完整起见我还是要多说一句，某些型转很不幸地内建于SQL之中从而无法回避（我觉得下述说明在这个地方可能没多大用处，但我不想把它们完全忽略）：
- 如果表表达式tx用作行子查询，那么tx所表示的表t就应该只有一行r，将并且表t型转为行r。注意：子查询一词在SQL上下文中随处可见。第12章将详细解释子查询；在其之前，你可以将其不太严谨地看成一个由括号封闭的SELECT表达式。
- 如果表表达式tx用作标量子查询，那么tx所表示的表应该只有一行一列，因此也只能包含一个值v，并且表t双重型转为值v。注意：此种情况尤其会在SQL风格的聚集计算中出现（参见第7章）。
- 实践中，在ALL或ANY比较rxsq中的行表达式rx，一般由一个简单的标量表达式构成，此时标量表达式所表示的标量值实际上被型转为只包含此标量值的行。在rxsq中：（a）是后接ALL或ANY的“<”或“>”比较运算符；（b）sq是子查询。注意：在本书中，使用行表达式一词表示行子查询或行选择器调用（行选择器是我对SQL中所谓的行值构建器（row value constructor）的叫法，参见第3章）。换句话说，我使用行表达式（row expression）来表示任何代表一个行的表达式，就像我用表表达式（table expression）来表示任何代表一个表的表达式一样。ALL或ANY比较在第11章中进行详细讨论。
最后，SQL在与字符串相关的极特殊场合也使用术语型转（coercion)。不过，其细节超出了本书范围。