<chapter Id="typeconv">
<!-- <title>Type Conversion</title> -->
<title>型変換</title>
<indexterm><primary sortas="かたへんかん">型変換</primary></indexterm>
<indexterm><primary>SQL</primary><secondary sortas="かたへんかん">型変換</secondary></indexterm>
<para>
<!-- 
<acronym>SQL</acronym> queries can, intentionally or not, require
mixing of different data types in the same expression. 
<productname>Postgres</productname> has extensive facilities for
evaluating mixed-type expressions. -->

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

<para>
<!-- In many cases a user will not need
to understand the details of the type conversion mechanism.
However, the implicit conversions done by <productname>Postgres</productname>
can affect the results of a query.  When necessary, these results
can be tailored by a user or programmer
using <emphasis>explicit</emphasis> type coercion. -->

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

<para>
<!--
This chapter introduces the <productname>Postgres</productname>
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. -->

この章では、<productname>Postgres</productname>の型変換機構とその規定について紹介します。特定のデータ型、使用できる関数と演算子についての情報については、<citetitle>&user-guide;</citetitle>と<citetitle>&programmer-guide;</citetitle>の関連する節を参照してください。

</para>

<para>
<!-- 
The Programmer's Guide has more details on the exact algorithms used for
implicit type conversion and coercion. -->

<citetitle>&programmer-guide;</citetitle>には、暗黙的な型変換と強制に使用される正確なアルゴリズムについて、より詳細に記述されています。

</para>

<sect1 id="typeconv-overview">
<!-- <title>Overview</title>-->
<title>概要</title>

<para>
<!-- 
<acronym>SQL</acronym> is a strongly typed language. That is, every data item
has an associated data type which determines its behavior and allowed usage.
<productname>Postgres</productname> has an extensible type system that is
much more general and flexible than other <acronym>RDBMS</acronym> implementations.
Hence, most type conversion behavior in <productname>Postgres</productname>
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.
-->

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

</para>

<para>
<!-- 
The <productname>Postgres</productname> 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 <acronym>SQL</acronym> language definition allows specifying type
names with strings, and this mechanism can be used in
<productname>Postgres</productname> to start the parser down the correct
path. For example, the query -->

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

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

<para>この問い合わせは、<type>text</type>と<type>point</type>という2つの型を指定した文字列を持ちます。型が指定されていない場合、後述するように、後の段階で解決されるように、とりあえず場所を確保するための型である<firstterm>unknown</firstterm>が割り当てられます。<indexterm><primary>unknown</primary></indexterm>

</para>

<para>
<!-- 
There are four fundamental <acronym>SQL</acronym> constructs requiring
distinct type conversion rules in the <productname>Postgres</productname>
parser: -->

<productname>Postgres</productname>には、個別の型変換ルールが必要な4つの基礎的な<acronym>SQL</acronym>構成要素があります。

</para>

<variablelist>
<varlistentry>
<term>
<!-- Operators -->演算子
</term>
<listitem>
<para>
<!-- <productname>Postgres</productname> allows expressions with
left- and right-unary (one argument) operators,
as well as binary (two argument) operators. -->

<productname>Postgres</productname>では、（引数が2つである）二項演算子と同様に、（引数が1つである）左方単項、右方単項演算子を持つ式が使用できます。
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<!-- Function calls -->関数呼び出し
</term>
<listitem>
<para>
<!-- 
Much of the <productname>Postgres</productname> 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.  Since <productname>Postgres</productname> permits function
overloading, the function name alone does not uniquely identify the function
to be called ___ the parser must select the right function based on the data
types of the supplied arguments. -->

<productname>Postgres</productname>の型システムの多くは、多くの関数の集合を持って構築されています。ある特定の問い合わせにおける関数呼び出しは引数を1つ以上もち、システムカタログ内で使用可能とされている関数定義に一致していなければいけません。<productname>Postgres</productname>は関数のオーバーロードを許可するので、関数名のみでは呼び出される関数を一意に識別しません。パーサーが、与えられる引数のデータ型に基づいて正しい関数を選択しなければいけません。

</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<!-- Query targets -->問い合わせの対象
</term>
<listitem>
<para>
<!-- 
<acronym>SQL</acronym> INSERT and UPDATE statements place the results of
expressions into a table. The expressions in the query must be matched up
with, and perhaps converted to, the types of the target columns. -->

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

</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<!-- UNION and CASE constructs -->
UNION構造体とCASE構造体
</term>
<listitem>
<para>
<!-- 
Since all select results from a UNION SELECT statement must appear in a single
set of columns, the types of the results
of each SELECT clause must be matched up and converted to a uniform set.
Similarly, the result expressions of a CASE construct must be coerced to
a common type so that the CASE expression as a whole has a known output type.
-->

UNION SELECT文からの選択結果はすべて、ある1つのカラム集合に現れなければいけませんので、各SELECT句の型は統一された集合に一致し変換できる必要があります。同様に、CASE構造体の結果の式は、CASE式が全体として既知の出力型を持つようになるために、CASE構成要素の結果式は共通の型を強制する必要があります。

</para>
</listitem>
</varlistentry>
</variablelist>

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

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

<para>
<!-- 
The <productname>Postgres</productname> 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 these
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.
-->

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

</para>

<para>
<!-- 
An additional heuristic is provided in the parser to allow better guesses
at proper behavior for <acronym>SQL</acronym> standard types. There are
several basic <firstterm>type categories</firstterm> defined: boolean,
numeric, string, bitstring, datetime, timespan, geometric, network,
and user-defined. Each category, with the exception of user-defined, has
a <firstterm>preferred type</firstterm> which is preferentially selected
when there is ambiguity.
In the user-defined category, each type is its own preferred type.
Ambiguous expressions (those with multiple candidate parsing solutions)
can often be resolved when there are multiple possible built-in types, but
they will raise an error when there are multiple choices for user-defined
types. -->

更に、<acronym>SQL</acronym>標準型用の適切な動作をうまく推測できるようにするための発見的方法がパーサーに提供されています。基本的な<firstterm>型カテゴリ</firstterm>は、ブール値、数値、文字列、ビット文字列、日付、時間、幾何学データ、ネットワーク、ユーザー定義があります。<indexterm><primary sortas="かたかてごり">型カテゴリ</primary></indexterm><indexterm><primary sortas="かたへんかん">型変換</primary><secondary sortas="かたかてごり">型カテゴリ</secondary></indexterm>ユーザー定義を除いた各カテゴリは、あいまいさがある場合に優先的に選択される<firstterm>好ましい型</firstterm>を持ちます。<indexterm><primary sortas="このましいかた">好ましい型</primary></indexterm><indexterm><primary sortas="かたへんかん">型変換</primary><secondary sortas="このましいかた">好ましい型</secondary></indexterm>ユーザー定義カテゴリでは、それぞれの型はそれ自身の好ましい型です。あいまいな式（複数の解析結果侯補を持つもの）は、複数の可能な組み込み型があればしばしば解決されますが、複数のユーザー定義型選択子がある場合にはエラーが発生します。

</para>

<sect2>
<!-- <title>Guidelines</title> -->
<title>ガイドライン</title>

<para>
<!-- 
All type conversion rules are designed with several principles in mind:
-->
すべての型変換ルールは次のようないくつかの基本的な考え方に基づいて設計されています。</para>


<itemizedlist mark="bullet" spacing="compact">
<listitem>
<para>
<!-- 
Implicit conversions should never have surprising or unpredictable outcomes.
-->

暗黙的な変換は、びっくりするような、あるいは、予想できない結果を持つべきではない。
</para>
</listitem>

<listitem>
<para>
<!-- 
User-defined types, of which the parser has no a-priori knowledge, should be
"higher" in the type hierarchy. In mixed-type expressions, native types 
shall always be converted to a user-defined type (of course, only if 
conversion is necessary). -->

パーサーがあらかじめ知ることのないユーザー定義型は型の階層内で「より高位」にあるべきです。型が混在する式では、固有型は常にユーザー定義型に変換されます（もちろん、変換が必要なときのみです）。
</para>
</listitem>

<listitem>
<para>
<!-- 
User-defined types are not related. Currently, 
<productname>Postgres</productname> 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. -->

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

</para>
</listitem>

<listitem>
<para>
<!-- 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. -->

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

</para>

<para>
<!-- 
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. -->

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

</para>
</listitem>
</itemizedlist>
</sect2>
</sect1>

<sect1 id="typeconv-oper">
<!-- <title>Operators</title>-->
<title>演算子</title>
<indexterm><primary sortas="えんざんし">演算子</primary></indexterm>
<procedure>
<!-- <title>Operator Type Resolution</title>-->
<title>演算子型の解決</title>
<indexterm><primary sortas="えんざんし">演算子</primary><secondary sortas="かいけつ">解決</secondary></indexterm>
<step performance="required">
<para>
<!-- Check for an exact match in the pg_operator system catalog. -->
pg_operatorシステムカタログ内で正確に一致するかどうかを点検します。

</para>

<substeps>
<step performance="optional">
<para>
<!-- 
If one argument of a binary operator is <type>unknown</type> type,
then assume it is the same type as the other argument for this check.
Other cases involving <type>unknown</type> will never find a match at
this step. -->

二項演算子の1つの引数が<type>unknown</type>型であった場合、このチェックのもう片方の引数と同一の型であると仮定します。他の<type>unknown</type>を含む場合は、この段階では対を見つけることはありません。

</para>
</step>
</substeps>
</step>

<step performance="required">
<para>
<!-- Look for the best match. -->
最も合うものを検索します。
</para>
<substeps>
<step performance="required">
<para>
<!-- 
Make a list of all operators of the same name for which the input types
match or can be coerced to match.  (<type>unknown</type> literals are
assumed to be coercible to anything for this purpose.)  If there is only
one, use it; else continue to the next step. -->

入力型が合う、もしくは合うように型強制することができる、同じ名前を持つ全演算子の一覧を作成します（<type>unknown</type>リテラルはこの目的では何にでも型強制できるとみなされます）。もし1つしかない場合はそれを使います。それ以外の場合は次の段階に進みます。

</para>
</step>
<step performance="required">
<para>
<!-- 
Run through all candidates and keep those with the most exact matches
on input types.  Keep all candidates if none have any exact matches.
If only one candidate remains, use it; else continue to the next step.
-->

すべての侯補を検索し、入力型に最も正確に合うものを残します。もし正確に合うものがなければすべての侯補を残します。1つの侯補しか残らない場合、それを使います。それ以外の場合は次の段階に進みます。

</para>
</step>
<step performance="required">
<para>
<!-- 
Run through all candidates and keep those with the most exact or
binary-compatible matches on input types.  Keep all candidates if none have
any exact or binary-compatible matches.
If only one candidate remains, use it; else continue to the next step.
-->

すべての侯補を検索し、入力型に最も正確に合う、もしくはバイナリ互換性のあるものを残します。もし正確に合うものかバイナリ互換性のあるものがなければすべての侯補を残します。1つの侯補しか残らない場合、それを使います。それ以外の場合は次の段階に進みます。

</para>
</step>
<step performance="required">
<para>
<!-- 
Run through all candidates and keep those that accept preferred types at
the most positions where type coercion will be required.
Keep all candidates if none accept preferred types.
If only one candidate remains, use it; else continue to the next step.
-->

すべての侯補を検索し、型強制が要求される最も多くのポジションの好ましい型を受け入れるものを残します。好ましい型を受け入れるものがなければすべての侯補を残します。1つの侯補しか残らない場合、それを使います。それ以外の場合は次の段階に進みます。

</para>
</step>
<step performance="required">
<para>
<!-- 
If any input arguments are "unknown", check the type categories accepted
at those argument positions by the remaining candidates.  At each position,
select "string"
category if any candidate accepts that category (this bias towards string
is appropriate since an unknown-type literal does look like a string).
Otherwise, if all the remaining candidates accept the same type category,
select that category; otherwise fail because
the correct choice cannot be deduced without more clues.  Also note whether
any of the candidates accept a preferred datatype within the selected category.
Now discard operator candidates that do not accept the selected type category;
furthermore, if any candidate accepts a preferred type at a given argument
position, discard candidates that accept non-preferred types for that
argument. -->

もし入力引数で「unknown」のものがあれば、残った侯補からそれらの引数の位置において受け入れられる型カテゴリをチェックします。もしそのカテゴリを受け入れる侯補があれば、それぞれのポジションで「string」カテゴリを選択します（unknown型のリテラルは確かに文字列のように見えるので、このstringへのバイアスは適しています）。そうでなければ、もし残ったすべての侯補が同じ型カテゴリを受け入れる場合はそのカテゴリを選択します。そうでもなければ失敗します。なぜならさらに手掛りがなければ正しい選択が演繹されることができないからです。さらに、侯補の中で、選択されたカテゴリ内で好ましい型を受け入れるものがあるかどうか注意してください。ここで選択された型カテゴリを受け入れない演算子侯補は捨てます。さらに、もし侯補で好ましい型を与えられた
引数位置で受け入れるものがあれば、その引数の好ましい型ではない侯補を捨てます。

</para>
</step>
<step performance="required">
<para>
<!-- 
If only one candidate remains, use it.  If no candidate or more than one
candidate remains,
then fail. -->

もし1つの侯補しか残らない場合、それを使います。もし1つの侯補も残らない場合、もしくは1つより多い侯補が残る場合は失敗します。

</para>
</step>
</substeps>
</step>
</procedure>

<sect2>
<!-- <title>Examples </title>-->
<title>例</title>

<sect3>
<!-- <title>Exponentiation Operator</title> -->
<title>指数演算子</title>

<para>
<!-- There is only one exponentiation
operator defined in the catalog, and it takes arguments of type 
<type>double precision</type>.
The scanner assigns an initial type of <type>int4</type> to both arguments
of this query expression: -->

カタログ内に定義された指数演算子は1つだけ存在し、<type>double precision</type>型の引数をとります。スキャナは、次の問い合わせの式の両方の引数に<type>int4</type>という初期段階での型を割り当てます。</para>

<programlisting>
tgl=> select 2 ^ 3 AS "Exp";
 Exp
-----
   8
(1 row)
</programlisting>

<!-- So the parser does a type conversion on both operands and the query
is equivalent to -->
<para>ゆえに、パーサーは両引数に型変換を行い、上の問い合わせは以下の2つのどちらかと同じものになります。</para>

<programlisting>
tgl=> select CAST(2 AS double precision) ^ CAST(3 AS double precision) AS "Exp";
 Exp
-----
   8
(1 row)
</programlisting>

<!-- or -->

<programlisting>
tgl=> select 2.0 ^ 3.0 AS "Exp";
 Exp
-----
   8
(1 row)
</programlisting>


<note>
<para>
<!-- 
This last form has the least overhead, since no functions are called to do
implicit type conversion. This is not an issue for small queries, but may
have an impact on the performance of queries involving large tables.
-->

暗黙的な型変換を行う関数を呼び出すことがありませんので、最後の形式が最もオーバーヘッドの少ないものになります。これは小さな問い合わせでは問題にはなりませんが、大きなテーブルを伴う問い合わせの性能に影響を与える可能性があります。
</para>
</note>
</sect3>

<sect3>
<!-- <title>String Concatenation</title> -->
<title>文字列の結合</title>

<para>
<!-- 
A string-like syntax is used for working with string types as well as for
working with complex extended types.
Strings with unspecified type are matched with likely operator candidates.
-->

文字列のような構文は、文字列型だけではなく、複雑な拡張された型の処理にも使われます。型指定のない文字列は演算子候補と同様の一致がなされます。

</para>

<para>
<!-- One unspecified argument: -->
1つの引数の型が指定されていない場合の例を示します。</para>

<programlisting>
tgl=> SELECT text 'abc' || 'def' AS "Text and Unknown";
 Text and Unknown
------------------
 abcdef
(1 row)
</programlisting>

<para>
<!-- 
In this case the parser looks to see if there is an operator taking 
<type>text</type> for both arguments. Since there is, it assumes that 
the second argument should be interpreted as of type <type>text</type>.
-->

この場合、パーサーは、<type>text</type>を両引数にとる演算子が存在するかどうかを検索します。これは存在しますので、パーサーは2番目の引数は<type>text</type>型として解釈すべきであると仮定をします。


</para>

<para>
<!-- Concatenation on unspecified types: -->
型指定のない結合の場合の例を示します。</para>

<programlisting>
tgl=> SELECT 'abc' || 'def' AS "Unspecified";
 Unspecified
-------------
 abcdef
(1 row)
</programlisting>

<para>
<!-- 
In this case there is no initial hint for which type to use, since no types
are specified in the query. So, the parser looks for all candidate operators
and finds that there are candidates accepting both string-category and
bitstring-category inputs.  Since string category is preferred when available,
that category is selected, and then the 
"preferred type" for strings, <type>text</type>, is used as the specific
type to resolve the unknown literals to. -->

この場合、問い合わせに型が何も指定されていませんので使用すべき型についてのヒントが初期段階において存在しません。ですので、パーサーはすべての侯補となる演算子を検索し、文字列カテゴリとビット文字列カテゴリの両方の入力を受け入れる侯補があることを発見します。有効である場合は文字列カテゴリのほうが好ましいので、そのカテゴリが選択されます。そして文字列の「好ましい型」である<type>text</type>がunknownのリテラルを解決する特定の型として使われます。

</para>
</sect3>

<sect3>
<!-- <title>Factorial</title> -->
<title>階乗</title>

<para>
<!-- 
This example illustrates an interesting result. Traditionally, the
factorial operator is defined for integers only. The <productname>Postgres</productname>
operator catalog has only one entry for factorial, taking an integer operand.
If given a non-integer numeric argument, <productname>Postgres</productname>
will try to convert that argument to an integer for evaluation of the
factorial. -->

この例は興味深い結果を示しています。歴史的に、階乗演算子は整数型についてのみ定義されています。<productname>Postgres</productname>演算子カタログは、階乗用に整数を引数としてとる1つのエントリしか持ちません。もし非整数の数字を引数として渡した場合、<productname>Postgres</productname>は、その引数を整数に変換して階乗計算を行うようになります。</para>

<programlisting>
tgl=> select (4.3 !);
 ?column?
----------
       24
(1 row)
</programlisting>

<note>
<para>
<!-- Of course, this leads to a mathematically suspect result,
since in principle the factorial of a non-integer is not defined.
However, the role of a database is not to teach mathematics, but
to be a tool for data manipulation. If a user chooses to take the
factorial of a floating point number, <productname>Postgres</productname>
will try to oblige. -->

非整数の階乗の原理が定義されていませんので、もちろん、これは数学的に疑わしい結果を導き出します。しかしデータベースの役割は、数学を教えるものではなく、データを操作する道具です。ユーザーが浮動小数点数値の階乗を計算することを選択したならば、<productname>Postgres</productname>はその要求に応えようとします。

</para>
</note>
</sect3>
</sect2>
</sect1>

<sect1 id="typeconv-func">
<!-- <title>Functions</title> -->
<title>関数</title>
<indexterm><primary sortas="かんすう">関数</primary></indexterm>
<procedure>
<!-- <title>Function Call Type Resolution</title> -->
<title>関数呼び出し型の解決</title>
<indexterm><primary sortas="かんすう">関数</primary><secondary sortas="よびだしのかいけつ">呼び出しの解決</secondary></indexterm>
<step performance="required">
<para>
<!-- Check for an exact match in the pg_proc system catalog.
(Cases involving <type>unknown</type> will never find a match at
this step.) -->

pg_procシステムカタログ内で一致するかどうかを点検します（<type>unknown</type>を含む場合、この段階で対を見つけることはありません）。

</para></step>
<step performance="required">
<para>
<!-- Look for the best match. -->
最もよく合うものを検索します。

</para>
<substeps>
<step performance="required">
<para>
<!-- 
Make a list of all functions of the same name with the same number of
arguments for which the input types
match or can be coerced to match.  (<type>unknown</type> literals are
assumed to be coercible to anything for this purpose.)  If there is only
one, use it; else continue to the next step. -->

入力型が合う、もしくは合うように型強制ができる、同じ名前かつ引数の数が同じ関数のすべての一覧を作成します（<type>unknown</type>リテラルはこの目的では何にでも型強制できるとみなされます）。もし1つしかなければそれを使います。そうでなければ次の段階に進みます。

</para>
</step>
<step performance="required">
<para>
<!-- 
Run through all candidates and keep those with the most exact matches
on input types.  Keep all candidates if none have any exact matches.
If only one candidate remains, use it; else continue to the next step.
-->

すべての侯補を検索し、入力型に最も正確に合うものを残します。正確に合うものが何もなければすべての侯補を残します。1つだけ侯補が残った場合はそれを使います。それ以外の場合は次の段階に進みます。

</para>
</step>
<step performance="required">
<para>
<!-- Run through all candidates and keep those with the most exact or
binary-compatible matches on input types.  Keep all candidates if none have
any exact or binary-compatible matches.
If only one candidate remains, use it; else continue to the next step.
-->

すべての侯補を検索し、入力型に最も正確に合う、もしくはバイナリ互換性のあるものを残します。もし正確に合うものかバイナリ互換性のあるものがなければすべての侯補を残します。1つの侯補しか残らない場合、それを使います。それ以外の場合は次の段階に進みます。

</para>
</step>
<step performance="required">
<para>
<!-- 
Run through all candidates and keep those that accept preferred types at
the most positions where type coercion will be required.
Keep all candidates if none accept preferred types.
If only one candidate remains, use it; else continue to the next step.
-->

すべての侯補を検索し、型強制が要求される最も多くの引数位置で好ましい型を受け入れるものを残します。好ましい型を受け入れるものがなければすべての侯補を残します。1つの侯補しか残らない場合、それを使います。それ以外の場合は次の段階に進みます。

</para>
</step>
<step performance="required">
<para>
<!-- 
If any input arguments are "unknown", check the type categories accepted
at those argument positions by the remaining candidates.  At each position,
select "string"
category if any candidate accepts that category (this bias towards string
is appropriate since an unknown-type literal does look like a string).
Otherwise, if all the remaining candidates accept the same type category,
select that category; otherwise fail because
the correct choice cannot be deduced without more clues.  Also note whether
any of the candidates accept a preferred datatype within the selected category.
Now discard operator candidates that do not accept the selected type category;
furthermore, if any candidate accepts a preferred type at a given argument
position, discard candidates that accept non-preferred types for that
argument. -->

入力引数で「unknown」のものがあった場合、それらの残った侯補に引数位置で受け入れられる型カテゴリをチェックします。もしそのカテゴリを受け入れる侯補が合った場合、それぞれのポジションで「string」を選択します（unknown型のリテラルは確かに文字列のように見えるので、このstringへのバイアスは適しています）。そうでなければ、もし残ったすべての侯補が同じ型カテゴリを受け入れる場合はそのカテゴリを選択します。そうでもなければ失敗します。なぜならさらに手掛りがなければ正しい選択が演繹されることができないからです。さらに、侯補の中で、選択されたカテゴリ内で好ましい型を受け入れるものがあるかどうか注意してください。ここで選択された型カテゴリを受け入れない演算子侯補は捨てます。さらに、もし侯補で好ましい型を与えられた引数ポジションで受け入れるものがあれば、その引数の好ましくない型を受け入れる侯補を捨てます。

</para>
</step>
<step performance="required">
<para>
<!-- 
If only one candidate remains, use it.  If no candidate or more than one
candidate remains,
then fail. -->

1つの侯補しか残らない場合、それを使います。もし侯補がない、もしくは1つより多い侯補が残る場合は失敗します。

</para>
</step>
</substeps>
</step>
<step performance="required">
<para>
<!-- 
If no best match could be identified, see whether the function call appears
to be a trivial type coercion request.  This happens if the function call
has just one argument and the function name is the same as the (internal)
name of some datatype.  Furthermore, the function argument must be either
an unknown-type literal or a type that is binary-compatible with the named
datatype.  When these conditions are met, the function argument is coerced
to the named datatype. -->

もしよく合うものが見つからなければ、その関数呼び出しが些細な型強制要求であるかどうかを見ます。これは、もし関数呼び出しが1つの引数しか持たず、関数名が他のデータ型の（内部的な）名前と同じだった場合に起こります。さらに、関数の引数は、unknown型リテラルか指定されたデータ型とバイナリ互換性がある型のどちらかでなければいけません。これらの条件が揃うと、関数の引数は指定されたデータ型に型強制されます。

</para>
</step>
</procedure>

<sect2>
<!-- <title>Examples</title> -->
<title>例</title>

<sect3>
<!-- <title>Factorial Function</title> -->
<title>階乗関数</title>

<para>
<!-- 
There is only one factorial function defined in the pg_proc catalog.
So the following query automatically converts the <type>int2</type> argument
to <type>int4</type>: -->

pg_procカタログには、階乗関数が1つのみ定義されています。ですから、次の問い合わせは自動的に<type>int2</type>引数を<type>int4</type>に変換されます。 </para>

<programlisting>
tgl=> select int4fac(int2 '4');
 int4fac
---------
      24
(1 row)
</programlisting>

<!-- and is actually transformed by the parser to -->
<para>そして、実際にはパーサーによって次のように変換されます。</para>
<programlisting>
tgl=> select int4fac(int4(int2 '4'));
 int4fac
---------
      24
(1 row)
</programlisting>
</sect3>

<sect3>
<!-- <title>Substring Function</title> -->
<title>部分文字列関数</title>
<indexterm><primary sortas="ぶぶんもじれつかんすう">部分文字列関数</primary></indexterm>
<para>
<!-- 
There are two <function>substr</function> functions declared in pg_proc. 
However,only one takes two arguments, of types <type>text</type> and 
<type>int4</type>. -->

pg_procには2つの<function>substr</function>関数が宣言されています。しかし、<type>text</type>型と<type>int4</type>型という2つの型を持つものは1つしかありません。

</para>

<para>
<!-- 
If called with a string constant of unspecified type, the type is matched up
directly with the only candidate function type: -->

型指定のない文字列定数を与えて呼び出した場合、その型は、1つの候補関数の型にただちに適合します。</para>

<programlisting>
tgl=> select substr('1234', 3);
 substr
--------
     34
(1 row)
</programlisting>

<para>
<!--
If the string is declared to be of type <type>varchar</type>, as might 
be the case if it comes from a table, then the parser will try to 
coerce it to become <type>text</type>: -->
あるテーブルから文字列を得るといった場合にあり得るものとして、文字列が<type>varchar</type>型として宣言されていた場合に、パーサーが文字列を<type>text</type>型に強制しようとするというものがあります。</para>

<programlisting>
tgl=> select substr(varchar '1234', 3);
 substr
--------
     34
(1 row)
</programlisting>
<!-- which is transformed by the parser to become -->
<para>上記のものは、パーサーによって次のように変換されます。</para>

<programlisting>
tgl=> select substr(text(varchar '1234'), 3);
 substr
--------
     34
(1 row)
</programlisting>

<note>
<para>
<!-- 
Actually, the parser is aware that <type>text</type> and <type>varchar</type>
are "binary compatible", meaning that one can be passed to a function that
accepts the other without doing any physical conversion.  Therefore, no
explicit type conversion call is really inserted in this case. -->

実際に、パーサーは<type>text</type>と<type>varchar</type>が「バイナリ互換性がある」ということを知っています。つまり、物理的変換を行わずにもう一方を受け入れる関数に渡されることができるということです。したがってこの場合、明示的な型変換呼び出しは実際には挿入されません。
</para>
</note>

<para>
<!-- 
And, if the function is called with an <type>int4</type>, the parser will
try to convert that to <type>text</type>: -->

<type>int4</type>型を使って呼び出された場合、パーサーは<type>text</type>に変換しようとします。 </para>

<programlisting>
tgl=> select substr(1234, 3);
 substr
--------
     34
(1 row)
</programlisting>
<!-- actually executes as -->
<para>上記のものは、実際には次のようになります。</para>
<programlisting>
tgl=> select substr(text(1234), 3);
 substr
--------
     34
(1 row)
</programlisting>
<!-- 
This succeeds because there is a conversion function text(int4) in the
system catalog. -->
<para>システムカタログにtext(int4)という変換関数があるので、これは成功します。

</para>
</sect3>
</sect2>
</sect1>

<sect1 id="typeconv-query">
<!-- <title>Query Targets</title> -->
<title>問い合わせの対象</title>

<procedure>
<!-- <title>Query Target Type Resolution</title> -->
<title>問い合わせの対象の型の解決</title>
<indexterm><primary sortas="といあわせのたいしょうのかたのかいけつ">問い合わせの対象の型の解決</primary></indexterm>
<step performance="required">
<para>
<!-- Check for an exact match with the target. -->
対象に正確に一致するかどうかをチェックします。

</para></step>
<step performance="required">
<para>
<!-- 
Otherwise, try to coerce the expression to the target type.  This will succeed
if the two types are known binary-compatible, or if there is a conversion
function.  If the expression is an unknown-type literal, the contents of
the literal string will be fed to the input conversion routine for the target
type. -->

なければ、式を対象の型に強制してみます。もし2つの型がバイナリ互換性があるものとして認識される、もしくは変換関数がある場合、これは成功します。もし式がunknown型リテラルの場合、リテラル文字列の内容は対象の型の入力変換ルーチンに与えられます。

</para></step>

<step performance="required">
<para>
<!-- If the target is a fixed-length type (e.g. <type>char</type> or 
<type>varchar</type>
declared with a length) then try to find a sizing function for the target
type.  A sizing function is a function of the same name as the type,
taking two arguments of which the first is that type and the second is an
integer, and returning the same type.  If one is found, it is applied,
passing the column's declared length as the second parameter. -->

対象が固定長な型（たとえば<type>char</type>や<type>varchar</type>型）ならば、大きさを調整する関数を探します。大きさを調整する関数は、同じ名前の型で、1つ目がその型、2つ目が整数という2つの引数をとり、同じ型を返すという関数です。もし1つが見つかれば、適用され、列の宣言された長さを2番目のパラメータとして渡します。

</para></step>

</procedure>

<sect2>
<!-- <title>Examples</title> -->
<title>例</title>

<sect3>
<!-- <title><type>varchar</type> Storage</title> -->
<title><type>varchar</type>の保存</title>
<indexterm><primary sortas="varcharのほぞん">varcharの保存</primary></indexterm>
<para>
<!-- 
For a target column declared as <type>varchar(4)</type> the following query
ensures that the target is sized correctly: -->

<type>varchar(4)</type>として宣言された対象のカラムへの以下の問い合わせでは、対象の大きさが正確であることが保証されています。</para>

<programlisting>
tgl=> CREATE TABLE vv (v varchar(4));
CREATE
tgl=> INSERT INTO vv SELECT 'abc' || 'def';
INSERT 392905 1
tgl=> SELECT * FROM vv;
  v
------
 abcd
(1 row)
</programlisting>
<!-- 
What's really happened here is that the two unknown literals are resolved
to text by default, allowing the <literal>||</literal> operator to be
resolved as text concatenation.  Then the text result of the operator
is coerced to varchar to match the target column type.  (But, since the
parser knows that text and varchar are binary-compatible, this coercion
is implicit and does not insert any real function call.)  Finally, the
sizing function <literal>varchar(varchar,int4)</literal> is found in the system
catalogs and applied to the operator's result and the stored column length.
This type-specific function performs the desired truncation. -->

<para>ここで実際に起こったのは、2つのunknownリテラルがデフォルトでtextへと型解決され、<literal>||</literal>演算子がtextの連結として評価されるということです。そして演算子のテキスト結果は対象の列の型に合うようにvarcharへ型強制されます（しかし、パーサーはtextとvarcharがバイナリ互換性があることを認識しているので、この型強制は暗黙のものであり、実際の関数呼び出しは挿入しません）。最後に、大きさを調整する関数<literal>varchar(varchar,int4)</literal>がシステムカタログの中から見つかり、演算子の結果と格納された列の長さに適用されます。この型特有の関数は期待される切り捨てを行います。
</para>
</sect3>
</sect2>
</sect1>

<sect1 id="typeconv-union-case">
<!-- <title>UNION and CASE Constructs</title> -->
<title>UNION構築子とCASE構築子</title>
<indexterm><primary sortas="UNIONこうちくしとCASEこうちくし">UNION構築子とCASE構築子</primary></indexterm>
<para>
<!-- 
The UNION and CASE 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.  CASE uses the identical algorithm to match
up its result expressions. -->

UNION構築子とCASE構築子は、単一の結果集合となるためには、似ていない可能性がある型と適合しなければいけません。解決アルゴリズムはUNIONのそれぞれの出力に別々に適応されます。CASEは、結果の式を適合するために、同一のアルゴリズムを使います。

</para>
<procedure>
<!-- <title>UNION and CASE Type Resolution</title>-->
<title>UNIONとCASEの型評価</title>

<step performance="required">
<para>
<!-- 
If all inputs are of type <type>unknown</type>, resolve as type
<type>text</type> (the preferred type for string category).
Otherwise, ignore the <type>unknown</type> inputs while choosing the type.
-->
もしすべての入力値が<type>unknown</type>型だった場合、<type>text</type>型（文字列カテゴリの好ましい型）として解釈されます。そうでない場合は、型を選ぶ間は<type>unknown</type>入力は無視します。
</para></step>

<step performance="required">
<para>
<!-- 
If the non-unknown inputs are not all of the same type category, fail.
-->
もしunknownではない入力値がすべて同じ型カテゴリでなければ失敗します。
</para></step>

<step performance="required">
<para>
<!-- 
If one or more non-unknown inputs are of a preferred type in that category,
resolve as that type. -->

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

<step performance="required">
<para>
<!-- Otherwise, resolve as the type of the first non-unknown input. -->
そうでなければ、最初のunknownではない入力値の型として解決されます。
</para></step>

<step performance="required">
<para>
<!-- 
Coerce all inputs to the selected type. -->
すべての入力値を選択された型に強制します。
</para></step>
</procedure>

<sect2>
<!-- <title>Examples</title> -->
<title>例</title>

<sect3>
<!-- <title>Underspecified Types</title> -->
<title>指定されない型</title>

<programlisting>
tgl=> SELECT text 'a' AS "Text" UNION SELECT 'b';
 Text
------
 a
 b
(2 rows)
</programlisting>
<!-- Here, the unknown-type literal 'b' will be resolved as type text.
-->
<para>ここでは、unknown型のリテラル'b'がtext型として解釈されます。
</para>
</sect3>

<sect3>
<!-- <title>Simple UNION</title> -->
<title>簡単なUNION</title>

<programlisting>
tgl=> SELECT 1.2 AS "Double" UNION SELECT 1;
 Double
--------
      1
    1.2
(2 rows)
</programlisting>
</sect3>

<sect3>
<!-- <title>Transposed UNION</title> -->
<title>転置されたUNION</title>

<para>
<!-- 
Here the output type of the union is forced to match the type of
the first/top clause in the union: -->
ここではunionの出力型は、そのunionの最初/頂点の句の型に合うよう強制されます。</para>

<programlisting>
tgl=> SELECT 1 AS "All integers"
tgl-> UNION SELECT CAST('2.2' AS REAL);
 All integers
--------------
            1
            2
(2 rows)
</programlisting>
<para>
<!-- 
Since <type>REAL</type> is not a preferred type, the parser sees no reason
to select it over <type>INTEGER</type> (which is what the 1 is), and instead
falls back on the use-the-first-alternative rule.
This example demonstrates that the preferred-type mechanism doesn't encode
as much information as we'd like.  Future versions of
<productname>Postgres</productname> may support a more general notion of
type preferences. -->

<type>REAL</type>は好ましい型ではないため、パーサーが<type>INTEGER</type>ではなくそれを選ぶ理由は何もなく（1は整数です）、代わりに最初の代替を使うというルールが適用されます。この例は好ましい型のメカニズムは、我々が望むほど多くの情報はコード化していないということを表しています。将来のバージョンの<productname>Postgres</productname>ではもっと一般的な型優先の考え方がサポートされるかもしれません。

</para>
</sect3>
</sect2>
</sect1>
</chapter>

<!-- Keep this comment at the end of the file
Local variables:
mode:sgml
sgml-omittag:t
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
sgml-parent-document:nil
sgml-default-dtd-file:"./reference.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:("/usr/lib/sgml/catalog")
sgml-local-ecat-files:nil
End:
-->
