UNION、CASEおよび関連する構文 #
SQL <literal>UNION</literal> constructs must match up possibly dissimilar
types to become a single result set. The resolution algorithm is
applied separately to each output column of a union query. The
<literal>INTERSECT</literal> and <literal>EXCEPT</literal> constructs resolve
dissimilar types in the same way as <literal>UNION</literal>.
Some other constructs, including
<literal>CASE</literal>, <literal>ARRAY</literal>, <literal>VALUES</literal>,
and the <function>GREATEST</function> and <function>LEAST</function>
functions, use the identical
algorithm to match up their component expressions and select a result
data type.
UNION SQL構文は、似ていない可能性がある型を1つの検索結果になるように適合させなければなりません。
解決アルゴリズムは1つのunion問い合わせの出力列ごとに適用されます。
INTERSECT構文とEXCEPT構文は、UNIONと同じ方法で、似ていない可能性がある型の解決を行います。
CASE、ARRAY、VALUESを含むいくつかの構文とGREATEST、LEAST関数は同一のアルゴリズムを使用して、その要素式を適合させ、結果のデータ型を選択します。
UNION、CASEおよび関連する構文の型解決
If all inputs are of the same type, and it is not <type>unknown</type>,
resolve as that type.
もし全ての入力値が同一型であり、unknownではない場合、その型として解決されます。
If any input is of a domain type, treat it as being of the domain's base type for all subsequent steps. 入力のいずれかがドメイン型であれば、以降の段階すべてでドメインの基本型であるかのように扱います。 [12]
If all inputs are of type <type>unknown</type>, resolve as type
<type>text</type> (the preferred type of the string category).
Otherwise, <type>unknown</type> inputs are ignored for the purposes
of the remaining rules.
もし全ての入力値がunknown型だった場合、text型（文字列カテゴリの優先される型）として解決されます。
そうでない場合、unknown入力は残りの規則のために無視されます。
If the non-unknown inputs are not all of the same type category, fail. もしunknownではない入力値が全て同じ型カテゴリでなければ失敗します。
Select the first non-unknown input type as the candidate type, then consider each other non-unknown input type, left to right. 最初のunknownではない入力データ型を候補の型として選択します。 それから、他のunknownではない入力データ型をそれぞれ左から右へ考慮します。 [13] If the candidate type can be implicitly converted to the other type, but not vice-versa, select the other type as the new candidate type. Then continue considering the remaining inputs. If, at any stage of this process, a preferred type is selected, stop considering additional inputs. 候補の型が暗黙的にある別の型に変換できるが、その逆はできない場合、その別の型を新しい候補の型として選択します。 それから残りの入力の考慮を続けます。 この処理のある段階で、優先される型が選択されれば、追加の入力の考慮を止めます。
Convert all inputs to the final candidate type. Fail if there is not an implicit conversion from a given input type to the candidate type. 入力値をすべて最終的な候補の型に変換します。 指定された入力型から候補の型への暗黙の変換が存在しない場合は失敗します。
Some examples follow. 以下に例を示します。
例10.10 Unionにおける指定された型の型解決
SELECT text 'a' AS "text" UNION SELECT 'b'; text ------ a b (2 rows)
Here, the unknown-type literal <literal>'b'</literal> will be resolved to type <type>text</type>.
ここで、unknown型のリテラル'b'はtextへと解決されます。
例10.11 簡単なUnionにおける型解決
SELECT 1.2 AS "numeric" UNION SELECT 1;
numeric
---------
1
1.2
(2 rows)
The literal <literal>1.2</literal> is of type <type>numeric</type>,
and the <type>integer</type> value <literal>1</literal> can be cast implicitly to
<type>numeric</type>, so that type is used.
numeric型のリテラル1.2とinteger型の値1は、暗黙的にnumericにキャスト可能です。
したがって、この型が使用されます。
例10.12 転置されたUNIONにおける型解決
SELECT 1 AS "real" UNION SELECT CAST('2.2' AS REAL);
real
------
1
2.2
(2 rows)
Here, since type <type>real</type> cannot be implicitly cast to <type>integer</type>,
but <type>integer</type> can be implicitly cast to <type>real</type>, the union
result type is resolved as <type>real</type>.
ここで、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
This failure occurs because <productname>PostgreSQL</productname> treats
multiple <literal>UNION</literal>s as a nest of pairwise operations;
that is, this input is the same as
この失敗は、PostgreSQLが複数のUNIONを二項演算の入れ子として扱うために起こります。すなわち、この入力は以下と同じです。
(SELECT NULL UNION SELECT NULL) UNION SELECT 1;
The inner <literal>UNION</literal> is resolved as emitting
type <type>text</type>, according to the rules given above. Then the
outer <literal>UNION</literal> has inputs of types <type>text</type>
and <type>integer</type>, leading to the observed error. The problem
can be fixed by ensuring that the leftmost <literal>UNION</literal>
has at least one input of the desired result type.
内側のUNIONは、上に挙げた規則に従って、型textになるものとして解決されます。
すると、外側のUNIONは型textとintegerの入力を受け取ることになりますので、上のようなエラーになります。
一番左のUNIONが望む結果型の入力を少なくとも1つ確実に受け取るようにすることで、この問題を修正できます。
<literal>INTERSECT</literal> and <literal>EXCEPT</literal> operations are
likewise resolved pairwise. However, the other constructs described in this
section consider all of their inputs in one resolution step.
INTERSECTとEXCEPT操作は同様に二項演算として解決されます。
しかしながら、この節のその他の構文は入力をすべて解決の段階の1つで考慮します。
[12]
Somewhat like the treatment of domain inputs for operators and
functions, this behavior allows a domain type to be preserved through
a <literal>UNION</literal> or similar construct, so long as the user is
careful to ensure that all inputs are implicitly or explicitly of that
exact type. Otherwise the domain's base type will be used.
演算子や関数に対するドメイン入力の取り扱いとある程度似ていて、この振舞いにより、利用者が注意して入力をすべて厳密な型であると明示的にもしくは暗黙的に保証する限り、ドメイン型をUNIONや類似の構成体に保存できます。
そうでなければ、ドメインの基本型が使われます。
[13]
For historical reasons, <literal>CASE</literal> treats
its <literal>ELSE</literal> clause (if any) as the <quote>first</quote>
input, with the <literal>THEN</literal> clauses(s) considered after
that. In all other cases, <quote>left to right</quote> means the order
in which the expressions appear in the query text.
歴史的な理由により、CASEは(もしあれば)そのELSE句を「最初の」入力として扱い、THEN句はその後で考慮します。
それ以外の場合では「左から右」は問い合わせテキスト内で式が現れる順を意味します。