SQL UNION構造は、単一の結果セットになるために、おそらく異なる型と一致する必要があります。 解決アルゴリズムは、和集合クエリの各出力列に別々に適用される。 INTERSECTとEXCEPTのコンストラクトは、UNIONと同じ方法で異なる型を解決します。 CASE、ARRAY、VALUES、GREATESTとLEAST関数など、他のいくつかの構造では、同じアルゴリズムを使用してコンポーネント式を照合し、結果データ型を選択します。
UNION、CASE、および関連するコンストラクトのタイプ解決
すべての入力が同じタイプで、
不明でない場合は、そのタイプとして解決します。いずれかの入力がドメインタイプの場合は、後続のすべてのステップでドメインの基本タイプとして扱います。
すべての入力の型が
不明の場合は、型text(文字列カテゴリの優先型) として解決します。 そうでなければ、未知の入力は、残りのルールの目的のために無視される。未知でない入力がすべて同じタイプカテゴリでない場合、失敗します。
最初の未知でない入力タイプを候補タイプとして選択してから、他の未知でない入力タイプを左から右に検討します。 候補タイプを他のタイプに暗黙的に変換できますが、その逆はできない場合は、他のタイプを新しい候補タイプとして選択します。 その後、残りの入力を検討し続ける。 このプロセスの任意の段階で、好ましいタイプが選択された場合、追加の入力を考慮することを中止する。
すべての入力を最終候補タイプに変換します。 指定された入力型から候補型への暗黙的な変換がない場合は失敗します。
例1.union内の指定されていない型の型解決
SELECTテキスト 'a' AS "テキスト" UNION SELECT 'b';
text
------
a
b
(2行) ここで、未知タイプのリテラル「b」は、テキストをタイプするように解決されます。
例2。単純なユニオンでの型解決
SELECT 1.2として「数値」UNION SELECT 1;
numeric
---------
1
1.2
(2行) リテラル1.2はnumeric型で、integer値1は暗黙的にnumericにキャストできるため、その型が使用されます。
例3。転置和集合の型解決
SELECT 1 AS "real" UNION SELECT CAST('2.2 'AS REAL);
real
------
1
2.2
(2行) ここで、型realは暗黙的にintegerにキャストできませんが、integerは暗黙的にrealにキャストできるため、和集合結果型はrealとして解決されます。
例4.ネストされたユニオンの型解決
SELECT NULL UNION SELECT NULL UNION SELECT 1;
エラー: UNION型のテキストと整数を一致させることはできませんこの失敗は、PostgreSQLが複数のUNIONをペアごとの操作のネストとして扱うために発生します。
(SELECT NULL UNION SELECT NULL) UNION SELECT 1;内側のUNIONは、上記の規則に従って、放出型テキストとして解決されます。 外側のUNIONにはtext型とinteger型の入力があり、エラーが観察されます。 この問題は、左端のUNIONが所望の結果タイプの少なくとも1つの入力を有することを保証することによって解決され得る。
INTERSECTとEXCEPT操作も同様にペアで解決されます。 しかし、このセクションで説明する他の構成は、1つの解決ステップでそれらの入力のすべてを考慮する。
演算子および関数のためのドメイン入力の処理のように、この動作は、ユーザがすべての入力が暗黙的または明示的にその正確なタイプであることを確実にするように注意している限り、UNIONまたは同様の構造を通してドメインタイプが保存されることを可能にする。 それ以外の場合、ドメインの基本タイプが使用されます。
歴史的な理由から、CASEはそのELSE句 (存在する場合) を「最初の」入力として扱い、その後にTHEN句が考慮されます。 他のすべての場合において、「左から右」は、式がクエリテキストに現れる順序を意味する。