[11/15開催: PostgreSQL Conference Japan 2019 参加受付中] 
他のバージョンの文書 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

5.6. UNION構成要素とCASE構成要素

SQL UNION UNION構成要素は、似ていない可能性がある型を1つの検索結果になるように適合させなければなりません。解決アルゴリズムは 1 つの union 問い合わせの出力列毎に適用されます。 INTERSECT 構成要素と EXCEPT 構成要素は UNION と同じ方法で、にていない可能性がある型の解決を行います。 CASE 構成要素もまた、同一のアルゴリズムを使用して、その要素式を適合させ、結果のデータ型を選択します。

UNIONCASE の型の解決

  1. もしすべての入力値がunknown型だった場合、 text型(文字列カテゴリの好ましい型)として解決されます。そうでない場合は、型を選ぶ間はunknown入力は無視します。

  2. もしunknownではない入力値がすべて同じ型カテゴリでなければ失敗します。

  3. 1つ以上のunknownではない入力値がそのカテゴリの好ましい型だった場合、その型として解決します。

  4. そうでなければ、最初のunknownではない入力値の型として解決されます。

  5. すべての入力値を選択された型に強制します。

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ではもっと一般的な型優先の考え方がサポートされるかもしれません。