SQL UNION UNION構成要素は、似ていない可能性がある型を1つの検索結果になるように適合させなければなりません。解決アルゴリズムは 1 つの union 問い合わせの出力列毎に適用されます。 INTERSECT 構成要素と EXCEPT 構成要素は UNION と同じ方法で、にていない可能性がある型の解決を行います。 CASE 構成要素もまた、同一のアルゴリズムを使用して、その要素式を適合させ、結果のデータ型を選択します。
UNION と CASE の型の解決
もしすべての入力値がunknown型だった場合、 text型（文字列カテゴリの好ましい型）として解決されます。そうでない場合は、型を選ぶ間はunknown入力は無視します。
もしunknownではない入力値がすべて同じ型カテゴリでなければ失敗します。
1つ以上のunknownではない入力値がそのカテゴリの好ましい型だった場合、その型として解決します。
そうでなければ、最初のunknownではない入力値の型として解決されます。
すべての入力値を選択された型に強制します。
Example 5-7. Union における指定されない型
tgl=> SELECT text 'a' AS "Text" UNION SELECT 'b'; Text ------ a b (2 rows)
ここでは、unknown型のリテラル'b'がtext型として解決されます。
Example 5-8. 簡単なUNIONにおける型変換
tgl=> SELECT 1.2 AS "Double" UNION SELECT 1;
Double
--------
1
1.2
(2 rows)
1.2 リテラルは double 精度型であり、数値カテゴリの好ましい型です。ですので、この型が使用されます。
Example 5-9. 転置されたUNIONにおける型変換
ここではunionの出力型は、そのunionの最初の句の型に合うよう強制されます。
tgl=> SELECT 1 AS "All integers"
tgl-> UNION SELECT CAST('2.2' AS REAL);
All integers
--------------
1
2
(2 rows)
REALは好ましい型ではないため、パーサが、（1の型である） INTEGERではなくそれを選ぶ理由は何もなく、代わりに最初の代替を使うというルールが適用されます。この例は好ましい型のメカニズムは、我々が望むほど多くの情報はコード化していないということを表しています。将来のバージョンの PostgreSQLではもっと一般的な型優先の考え方がサポートされるかもしれません。