<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>PostgreSQL</productname> has an extensible type system that is more general and flexible than other <acronym>SQL</acronym> implementations. Hence, most type conversion behavior in <productname>PostgreSQL</productname> is governed by general rules rather than by ad hoc heuristics. This allows the use of mixed-type expressions even with user-defined types. SQLは強く型付けされた言語です。 つまり、各データ項目は、その動作と許される使用方法を決定するデータ型を所有しています。 PostgreSQLには、他のSQLの実装よりもより一般的で柔軟性のある、拡張可能な型システムがあります。 このために、PostgreSQLでのほとんどの型変換の動作は、特定の目的について勝手に作り上げられることなく一般的な規則で管理されています。 これにより、ユーザ定義型についても型の混在する式を使用できます。
The <productname>PostgreSQL</productname> scanner/parser divides lexical elements into five fundamental categories: integers, non-integer numbers, strings, identifiers, and key words. Constants of most non-numeric types are first classified as strings. The <acronym>SQL</acronym> language definition allows specifying type names with strings, and this mechanism can be used in <productname>PostgreSQL</productname> to start the parser down the correct path. For example, the query: PostgreSQLのスキャナ/パーサは字句要素を、整数、非整数値、文字列、識別子、キーワードという5個の基礎カテゴリに分解します。 ほとんどの非数値型定数は、まず文字列にクラス分けされます。 SQL言語定義では、文字列で型の名前を指定することを許していて、パーサが正しい手順に沿って処理を始められるようにPostgreSQLも採用しています。 例えば、以下のような問い合わせを考えてみましょう。
SELECT text 'Origin' AS "label", point '(0,0)' AS "value"; label | value --------+------- Origin | (0,0) (1 row)
has two literal constants, of type <type>text</type> and <type>point</type>.
If a type is not specified for a string literal, then the placeholder type
<type>unknown</type> is assigned initially, to be resolved in later
stages as described below.
この問い合わせは、textとpointという2つの型を指定したリテラル定数を持ちます。
文字列リテラルに型が指定されていない場合、後述するように、後の段階で解決されるようにとりあえず場所を確保するための型であるunknownが割り当てられます。
There are four fundamental <acronym>SQL</acronym> constructs requiring distinct type conversion rules in the <productname>PostgreSQL</productname> parser: PostgreSQLのパーサには、個別の型変換規則が必要な4つの基礎的なSQL構成要素があります。
Much of the <productname>PostgreSQL</productname> type system is built around a rich set of functions. Functions can have one or more arguments. Since <productname>PostgreSQL</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. PostgreSQL型システムの大部分は、高度な関数群によって構築されています。 関数は複数の引数を取ることができます。 PostgreSQLでは関数のオーバーロードが可能ですので、関数名だけでは呼び出すべき関数を一意に識別できません。 パーサは、提供される引数のデータ型に基づいて、正しい関数を選択しなければなりません。
<productname>PostgreSQL</productname> allows expressions with prefix (one-argument) operators, as well as infix (two-argument) operators. Like functions, operators can be overloaded, so the same problem of selecting the right operator exists. PostgreSQLでは、（引数が2つの）中置演算子と同様に、（引数が1つの）前置演算子を持つ式が使用できます。 関数と同様、演算子もオーバーロード可能ですので、正しい演算子を選択する時に同じ問題が存在します。
<acronym>SQL</acronym> <command>INSERT</command> and <command>UPDATE</command> statements place the results of
expressions into a table. The expressions in the statement must be matched up
with, and perhaps converted to, the types of the target columns.
SQLのINSERTとUPDATE文は式の結果をテーブルに格納します。
文内の式は対象となる列の型に一致する、または、変換できるものである必要があります。
UNION、CASE、および関連する構文
Since all query results from a unionized <command>SELECT</command> statement
must appear in a single set of columns, the types of the results of each
<command>SELECT</command> clause must be matched up and converted to a uniform set.
Similarly, the result expressions of a <literal>CASE</literal> construct must be
converted to a common type so that the <literal>CASE</literal> expression as a whole
has a known output type. Some other constructs, such
as <literal>ARRAY[]</literal> and the <function>GREATEST</function>
and <function>LEAST</function> functions, likewise require determination of a
common type for several subexpressions.
UNIONを構成するSELECT文からの選択結果は全て、ある1つの列集合として現れなければいけませんので、各SELECT句の結果型は統一された集合に一致し変換できる必要があります。
同様に、CASE構文が全体として既知の出力型を持つようになるために、CASE構文の結果式は共通の型に変換される必要があります。
ARRAY[]のような他のいくつかの構文やGREATEST関数、LEAST関数は、同様に副式に対して共通の型の決定を要求します。
The system catalogs store information about which conversions, or <firstterm>casts</firstterm>, exist between which data types, and how to perform those conversions. Additional casts can be added by the user with the <xref linkend="sql-createcast"/> command. (This is usually done in conjunction with defining new data types. The set of casts between built-in types has been carefully crafted and is best not altered.) システムカタログには、どのデータ型の間にどのような変換、すなわちキャストがあるのか、また、その変換をどのように実行するのかに関する情報を格納します。 ユーザはCREATE CASTコマンドを使用してキャストを追加できます。 （これは通常新しいデータ型を定義する時にまとめて行われます。 組み込み型間のキャスト集合は注意深く作成されており、変更しないことが最善です。）
An additional heuristic provided by the parser allows improved determination
of the proper casting behavior among groups of types that have implicit casts.
Data types are divided into several basic <firstterm>type
categories</firstterm>, including <type>boolean</type>, <type>numeric</type>,
<type>string</type>, <type>bitstring</type>, <type>datetime</type>,
<type>timespan</type>, <type>geometric</type>, <type>network</type>, and
user-defined. (For a list see <xref linkend="catalog-typcategory-table"/>;
but note it is also possible to create custom type categories.) Within each
category there can be one or more <firstterm>preferred types</firstterm>, which
are preferred when there is a choice of possible types. With careful selection
of preferred types and available implicit casts, it is possible to ensure that
ambiguous expressions (those with multiple candidate parsing solutions) can be
resolved in a useful way.
暗黙のキャストを持つデータ型間の処理において、適切なキャスト処理のより良い決定を行えるようパーサは追加の自律機構を備えています。
データ型は、boolean、numeric、string、bitstring、datetime、timespan、geometric、network、及びユーザ定義を含むいくつかの基本的な型カテゴリに分けられます。
（一覧は表 53.65を参照してください。ですが、独自の型カテゴリを作成するのも可能なことに注意してください。）
各カテゴリには、候補となる型の選択があった場合に、優先される1つ以上の優先される型がある場合があります。
優先される型と利用可能な暗黙のキャストを注意して選択すれば、曖昧な式（複数の解析結果候補を持つもの）が有効な方法で解決されることを保証することが可能です。
All type conversion rules are designed with several principles in mind: 全ての型変換規則は次のようないくつかの基本的な考え方に基づいて設計されています。
Implicit conversions should never have surprising or unpredictable outcomes. 暗黙的な変換は、意外な、あるいは予想できない結果を決して生成させてはなりません。
There should be no extra overhead in the parser or executor if a query does not need implicit type conversion. That is, if a query is well-formed and the types already match, then the query should execute without spending extra time in the parser and without introducing unnecessary implicit conversion calls in the query. 暗黙的な型変換を必要としない問い合わせの場合、パーサやエグゼキュータに余計なオーバーヘッドがあるべきではありません。 つまり、問い合わせ文がきちんとまとめられ、型が既に一致するものになっていれば、パーサ内で余計な時間を費やさず、また、問い合わせに不要な暗黙的な型変換関数が使用されないように、問い合わせは処理されるべきです。
Additionally, if a query usually requires an implicit conversion for a function, and if then the user defines a new function with the correct argument types, the parser should use this new function and no longer do implicit conversion to use the old function. さらに、もし問い合わせが関数のために暗黙的な変換を通常要求しており、そして、ユーザが正しい引数型を持つ関数を新しく定義した場合、パーサはこの新しい関数を使うべきであり、もはや古い関数を使うために暗黙的な変換を行わないようにすべきです。