「不明」と型推論のルールは何ですか？

実際、私が答えようとする3つの質問があります。

1. unknownの目的は何ですか ？

   これは、SQLステートメントでNULLおよび文字列リテラルに最初に割り当てられたデータ型です。そのようなリテラルが割り当てられた場合、タイプtext すぐに、正しいタイプを推測するのは難しいでしょう。

   たとえば、myfunc('hello')が必要です。 myfunc(character varying)を呼び出す 、ただし、textからキャストされた暗黙の型はありません character varying （作成するとあいまいさが発生します）。

2. SELECT nullがなぜ タイプunknownの列を返します ？

   従来の答えは、ユーザーがタイプを指定しなかったためです。

   ただし、この動作には問題があります。たとえば、次のようなテーブルを作成する場合：

   CREATE TABLE test
      AS SELECT 'hello';
   

   タイプunknownの列になってしまいます 、これは望ましくなく、さらに問題を引き起こします。タイプunknown 実際には、ユーザーに表示するのではなく、実装の詳細を表示する必要があります。

   したがって、このコミット PostgreSQLv10からの動作が変更されました。unknown s SELECTに残っている またはRETURNING リストはtextに強制されます 、およびタイプunknownの列を使用してテーブルを作成することはできません 。

3. SELECT NULL UNION SELECT 42が選ばれるのはなぜですか 動作しますが、SELECT NULL UNION SELECT NULL UNION SELECT 42ではありません ？

   これは、型変換ルール によるものです。 。UNION は結合性のままなので、後者のクエリは次のように解釈されます

   (SELECT NULL UNION SELECT NULL) UNION SELECT 42;
   

   これで最初のUNION データ型textに解決されます ルール3のため：

   これにより、2番目のUNIONのタイプを解決しようとしたときにエラーが発生します ルール4のため：

   一方、クエリでは

   SELECT NULL UNION SELECT 42;
   

   「NULL」のタイプはunknown 、および「42」のタイプはinteger （小数点のない数値リテラル用に選択されたタイプ）。

   ルール5

   integerであるため、ここでは適用されません。 そのカテゴリで推奨されるタイプではありません（oidになります） およびdouble precision ）、ルール6が使用されます：

   これにより、integerのタイプになります。 。