Chapter 6. Type Conversion

Table of Contents
概要
演算子
関数
問い合わせの対象
UNION 問い合わせ

SQL queries can, intentionally or not, require mixing of different data types in the same expression. Postgres has extensive facilities for evaluating mixed-type expressions.

意図的か意図的でないかに関らず、 1 つの式の中に異なる型を混ぜ合わ せた式を SQL の問い合わせでは持つことができま す。Postgres は異なる型が混在する式の 評価に関して幅広い能力を持っています。

In many cases a user will not need to understand the details of the type conversion mechanism. However, the implicit conversions done by Postgres can affect the apparent results of a query, and these results can be tailored by a user or programmer using explicit type coersion.

多くの場合、ユーザは型変換機構の詳細を理解する必要はありません。しか し、Postgres によって暗黙的に行なわれる変 換は問い合わせの結果にはっきりとした影響を及ぼし、それらの結果はユー ザまたはプログラマにより、明示的 に型の強制を用 いて目的とするものに合わせることができます。

This chapter introduces the Postgres type conversion mechanisms and conventions. Refer to the relevant sections in the User's Guide and Programmer's Guide for more information on specific data types and allowed functions and operators.

この章は Postgres の型変換機構とその規定 について紹介します。特定のデータ型、使用できる関数と演算子についての 情報については、ユーザガイドとプログラマガイドの関連する節を参 照して下さい。

The Programmer's Guide has more details on the exact algorithms used for implicit type conversion and coersion.

プログラマガイドには、暗黙的な型に関する変換と強制に使用される正 確なアルゴリズムについて、より詳細に記述されています。

概要

SQL is a strongly typed language. That is, every data item has an associated data type which determines its behavior and allowed usage. Postgres has an extensible type system which is much more general and flexible than other RDBMS implementations. Hence, most type conversion behavior in Postgres should be governed by general rules rather than by ad-hoc heuristics to allow mixed-type expressions to be meaningful, even with user-defined types.

SQL は強く型付けされた言語です。つまり、各データ 項目は、その動作と許される使用方法を決定するデータ型を所有していま す。Postgres は、他の RDBMS の実装よりもより一般的で柔軟性のある、幅広い 型システムを持ちます。ゆえに、Postgres で のほとんどの型変換の動作は、ユーザ定義型についても型の混在する式を有 意義に使えるように、特定の目的について勝手に作り上げられることなく一 般的なルールで管理されるべきです。

The Postgres scanner/parser decodes lexical elements into only five fundamental categories: integers, floats, strings, names, and keywords. Most extended types are first tokenized into strings. The SQL language definition allows specifying type names with strings, and this mechanism is used by Postgres to start the parser down the correct path. For example, the query

tgl=> SELECT text 'Origin' AS "Label", point '(0,0)' AS "Value";
Label |Value
------+-----
Origin|(0,0)
(1 row)
has two strings, of type text and point. If a type is not specified, then the placeholder type unknown is assigned initially, to be resolved in later stages as described below.

Postgres のスキャナ/パーサは字句要素を、整 数、浮動小数点、文字列、名前、キーワードというわずか 5 個の基礎カテゴ リに解読します。ほとんどの拡張された型は、まず文字列にトークン化されま す。SQL 言語定義では、文字列で型の名前を指定すること を許しており、この手法はパーサが正しい手順に沿って処理を始められるよう に Postgres によって使用されています。例えば、

tgl=> SELECT text 'Origin' AS "Label", point '(0,0)' AS "Value";
Label |Value
------+-----
Origin|(0,0)
(1 row)
という問い合わせは textpoint という 2 つ の型を指定した文字列を持ちます。型が指定されていない場合、後述するよう に、後の段階で解決されるように、とりあえず場所を確保するための型、 unknown が割り当てられます。

There are four fundamental SQL constructs requiring distinct type conversion rules in the Postgres parser:

Postgres パーサ内の明確な型変換ルールを要求 する 4 つの基礎的な SQL 構成があります。

演算子

Postgres allows expressions with left- and right-unary (one argument) operators, as well as binary (two argument) operators.

Postgres では、(引数が 2 つである)二項演 算子と同様、(引数が 1 つである)左方単項、右方単項演算子を持つ式が使 用できます。

関数呼び出し

Much of the Postgres type system is built around a rich set of functions. Function calls have one or more arguments which, for any specific query, must be matched to the functions available in the system catalog.

Postgres の型システムの多くは、多くの関数 の集合を持って構築されています。ある特定の問い合わせにおける関数呼 び出しは引数を 1 つ以上もち、システムカタログ内で使用可能とされてい る関数定義に一致していなければいけません。

問い合わせの対象

SQL INSERT statements place the results of query into a table. The expressions in the query must be matched up with, and perhaps converted to, the target columns of the insert.

SQL のINSERT 文は問い合わせの結果をテーブルの中に 格納します。問い合わせ内の式は挿入される対象となるカラムに一致する、 または、変換できるものである必要があります。

UNION 問い合わせ

Since all select results from a UNION SELECT statement must appear in a single set of columns, the types of each SELECT clause must be matched up and converted to a uniform set.

UNION SELECT 文からの select 結果は全て、ある一つのカラム集合に現れ なければいけませんので、各 SELECT 句の型は統一された集合に一致するか 変換できる必要があります。

Many of the general type conversion rules use simple conventions built on the Postgres function and operator system tables. There are some heuristics included in the conversion rules to better support conventions for the SQL92 standard native types such as smallint, integer, and float.

一般的な型の変換ルールの多くは、Postgres 関数と演算子のシステムテーブルに組み込まれている簡単な規定を使用しま す。smallintintegerfloat といった、SQL92 標準に固有の型の変換をよりうまく サポートするために、変換ルールには特別に用意されたものもあります。

The Postgres parser uses the convention that all type conversion functions take a single argument of the source type and are named with the same name as the target type. Any function meeting this criteria is considered to be a valid conversion function, and may be used by the parser as such. This simple assumption gives the parser the power to explore type conversion possibilities without hardcoding, allowing extended user-defined types to use these same features transparently.

Postgres パーサは、全ての型変換関数は変換 元となる型の引数を 1 つとり、対象とする型と同じ名前の関数名となってい るという規定を用いています。この基準に従う関数は全て、有効な変換関数 とみなされ、パーサによって変換関数として使用される可能性があります。 この簡単な仮定によって、パーサは、直接コード内に記述することなく型変 換を表現できるように、ユーザ定義型を同一の機能を透過的に使用できるよ うに拡張できるようになっています。

An additional heuristic is provided in the parser to allow better guesses at proper behavior for SQL standard types. There are five categories of types defined: boolean, string, numeric, geometric, and user-defined. Each category, with the exception of user-defined, has a "preferred type" which is used to resolve ambiguities in candidates. Each "user-defined" type is its own "preferred type", so ambiguous expressions (those with multiple candidate parsing solutions) with only one user-defined type can resolve to a single best choice, while those with multiple user-defined types will remain ambiguous and throw an error.

更に、SQL 標準型用の適切な動作をよりうまく推測でき るようにするための特別に用意されたものもパーサに提供されています。ブ ール値、文字列、数値、地理的情報、ユーザ定義といった 5 つのカテゴリが 定義されています。ユーザ定義を除いた各カテゴリは、候補中の曖昧さを解 決するために使用される "好ましい型" を持ちます。各 "ユーザ定義" 型は それ自体が "好ましい型" となります。ですので、ある 1 つのユーザ定義型 のみを使った(解答を分析する際に複数の候補を持つ)曖昧な式は、1 つの 最善の選択肢に解決できます。一方、複数のユーザ定義型を使った曖昧な式 は曖昧なままになり、エラーが発生することになります。

Ambiguous expressions which have candidate solutions within only one type category are likely to resolve, while ambiguous expressions with candidates spanning multiple categories are likely to throw an error and ask for clarification from the user.

ある型カテゴリ内で解答の候補を持つ、曖昧な式は多分解決できるでしょう。 一方、複数のカテゴリに跨った候補を持つ曖昧な式は多分エラーが発生し、 ユーザによる解明が求められることになるでしょう。

ガイドライン

All type conversion rules are designed with several principles in mind:

全ての型変換ルールは次のような考えの数個の原理に基づいて設計されています。

  • Implicit conversions should never have suprising or unpredictable outcomes.

    暗黙的な変換は、予知、予想できない結果を持つべきではない。 ※suprising→suprising

  • User-defined types, of which the parser has no apriori knowledge, should be "higher" in the type heirarchy. In mixed-type expressions, native types shall always be converted to a user-defined type (of course, only if conversion is necessary).

    パーサが演繹的な知識を持たないユーザ定義型は型の階層内で "より高位" にあるべきです。型が混在する式では、固有型は常にユーザ定義型に変換さ れます。(もちろん、変換が必要な時のみです。)

  • User-defined types are not related. Currently, Postgres does not have information available to it on relationships between types, other than hardcoded heuristics for built-in types and implicit relationships based on available functions in the catalog.

    ユーザ定義型は関係を持ちません。現時点では、 Postgres は型の間における関係について、 組み込み型用に直接コードで特別に作成したものと、カタログ内の使用可 能な関数に基づいた暗黙的な関係を除いては、有効な情報を保有していま せん。

  • There should be no extra overhead from the parser or executor if a query does not need implicit type conversion. That is, if a query is well formulated and the types already match up, then the query should proceed without spending extra time in the parser and without introducing unnecessary implicit conversion functions into the query.

    暗黙的な型変換を必要としない問い合わせの場合、パーサやエクザキュー タに余計なオーバヘッドがあるべきではありません。つまり、問い合わせ がきちんとまとめられ、型が既に一致するものになっていれば、パーサ内 で余計な時間を費やすことがなく、また、問い合わせに不要な暗黙的な型 変換関数を導かないように問い合わせは処理されるべきです。

    Additionally, if a query usually requires an implicit conversion for a function, and if then the user defines an explicit function with the correct argument types, the parser should use this new function and will no longer do the implicit conversion using the old function.

    更に、もし問い合わせが通常は関数を使った暗黙的な変換を要求していたも のであり、そして、ユーザが正しい引数型をもつ関数を明示的に定義した場 合、パーサはこの新しい関数を使い、古い関数を使った暗黙的な変換を行な わないようにすべきです。