pgsql.cc 提供对 postgresql.org 官网内容的中文翻译，由 Pigsty 团队维护。
UNION、CASE及相关结构 #SQL 的UNION结构必须让可能不同的类型彼此匹配，以形成单一结果集。该解析算法会分别应用到联合查询的每个输出列。INTERSECT和EXCEPT结构以与UNION相同的方式解析不同类型。CASE、ARRAY、VALUES以及GREATEST和LEAST构造使用完全相同的算法来匹配其组成表达式并选择结果数据类型。
UNION、CASE及相关结构的类型解析
如果所有输入都是同一类型，且该类型不是unknown，就解析为该类型。
如果任何输入是域类型，则在后续所有步骤中都把它当作该域的基础类型。 [10]
如果所有输入都是unknown类型，则解析为text类型（字符串分类的首选类型）。否则，忽略unknown输入。
如果非unknown输入并非全都属于同一类型分类，则失败。
选择该分类中的首选类型（如果第一个非unknown输入类型恰好是首选类型，则选它）。
否则，选择最后一个能让所有在它之前的非unknown输入都隐式转换为它的非unknown输入类型。（这样的类型总是存在的，因为列表中至少第一个类型就满足这一条件。）
把所有输入都转换为所选类型。如果某个输入到所选类型不存在转换，则失败。
下面是一些示例。
例 10.10. 未充分指定类型的 UNION 中的类型解析
SELECT text 'a' AS "text" UNION SELECT 'b'; text ------ a b (2 rows)
这里，unknown类型字面量'b'会被解析为text类型。
例 10.11. 简单 UNION 中的类型解析
SELECT 1.2 AS "numeric" UNION SELECT 1;
numeric
---------
1
1.2
(2 rows)
字面量1.2的类型是numeric，而integer值1可以隐式转换为numeric，因此使用该类型。
例 10.12. 次序对调的 UNION 中的类型解析
SELECT 1 AS "real" UNION SELECT CAST('2.2' AS REAL);
real
------
1
2.2
(2 rows)
这里，由于real类型不能隐式转换为integer，而integer可以隐式转换为real，因此UNION结果类型被解析为real。
例 10.13. 嵌套 UNION 中的类型解析
SELECT NULL UNION SELECT NULL UNION SELECT 1; ERROR: UNION types text and integer cannot be matched
之所以失败，是因为PostgreSQL把多个UNION视为由成对操作组成的嵌套；也就是说，这个输入等同于：
(SELECT NULL UNION SELECT NULL) UNION SELECT 1;
根据上述规则，内层UNION会被解析为输出text类型。随后外层UNION的输入类型分别是text和integer，于是就得到上面的错误。解决办法是确保最左边的UNION至少有一个输入属于期望的结果类型。
INTERSECT和EXCEPT也同样按成对方式解析。不过，本节介绍的其他结构会在一次解析步骤中同时考虑它们的所有输入。
[10] 这在某种程度上类似于操作符和函数对域输入的处理方式；只要用户确保所有输入都隐式或显式地正好属于该域类型，这种行为就能让域类型在UNION或类似结构中得以保留。否则，将优先使用该域的基础类型。
译文有误、术语不当或页面显示问题，请到译文仓库 pgsty/pgdoc 报告译文问题。 英文原文本身的问题，请在当前版本的对应页面向上游反馈；上游不再修订已结束维护的版本。