概要SQLは強く型付けされた言語です。各データ項目は、その動作と許される使用方法を決定するデータ型を所有しています。PostgreSQLには、他のSQLの実装よりもより一般的で柔軟性のある、拡張可能な型システムがあります。このために、PostgreSQLでのほとんどの型変換の動作は、特定の目的について勝手に作り上げられることなく一般的な規則で管理されています。これにより、ユーザ定義型についても型の混在する式を使用できます。キーワードという5個の基礎カテゴリに分解します。ほとんどの非数値型定数は、まず文字列にクラス分けされます。SQL言語定義では、文字列で型の名前を指定することを許していて、パーサが正しい手順に沿って処理を始められるようにPostgreSQLも採用しています。以下のような問い合わせを考えてみましょう。row)この問い合わせは、textとpointという2つの型を指定したリテラル定数を持ちます。文字列リテラルに型が指定されていない場合、後述するように、後の段階で解決されるようにとりあえず場所を確保するための型であるunknownが割り当てられます。PostgreSQLのパーサには、個別の型変換規則が必要な4つの基礎的なSQL構成要素があります。関数呼び出しPostgreSQL型システムの大部分は、高度な関数群によって構築されています。関数は複数の引数を取ることができます。PostgreSQLでは関数のオーバーロードが可能ですので、関数名だけでは呼び出すべき関数を一意に識別できません。パーサは、提供される引数のデータ型に基づいて、正しい関数を選択しなければなりません。持つ式が使用できます。関数と同様、演算子もオーバーロード可能ですので、正しい演算子を選択する時に同じ問題が存在します。値の格納SQLのINSERTとUPDATE文は式の結果をテーブルの中に格納します。文内の式は対象となる列の型に一致する、または、変換できるものである必要があります。UNION、CASE、および関連する構文UNIONを構成するSELECT文からの選択結果は全て、ある1つの列集合として現れなければいけませんので、各SELECT句の結果型は統一された集合に一致し変換できる必要があります。同様に、CASE構文が全体として既知の出力型を持つようになるために、CASE構文の結果式は共通の型に変換される必要があります。これはARRAY構文でもGREATEST関数、LEAST関数でも同じです。システムカタログには、データ型間の変換(もしくはキャスト)が有効かどうかや、その変換の実行方法に関する情報を格納します。(これは通常新しいデータ型を定義する時にまとめて行われます。組み込み型間のキャスト集合は注意深く作成されており、また、変更しないことが最善です)。暗黙のキャストを持つデータ型間の処理において、パーサが適切なキャスト処理のより良い決定を行えるよう追加の自律機構を備えています。データ型は、boolean、numeric、string、bitstring、datetime、timespan、geometric、network、及びユーザ定義を含むいくつかの型カテゴリに分けられます。(表48-53の一覧を参照してください。独自の型カテゴリを作成可能なことに注意して下さい。各カテゴリは、候補となる型の選択があった場合に、好ましいとされる1つ以上の好ましい型を持ちます。好ましい型の選択と利用可能な暗黙のキャストに注意すれば、曖昧な式(複数の解析結果候補を持つもの)が有効な方法で解決されることを保証することが可能です。全ての型変換規則は次のようないくつかの基本的な考え方に基づいて設計されています。暗黙的な変換は、意外な、あるいは予想できない結果を決して生成させてはなりません。暗黙的な型変換を必要としない問い合わせの場合、パーサやエクゼキュータに余計なオーバーヘッドがあるべきではありません。問い合わせ文がきちんとまとめられ、型が既に一致するものになっていれば、パーサ内で余計な時間を費やさず、また、問い合わせに不要な暗黙的な型変換関数が使用されないように、問い合わせは処理されるべきです。問い合わせが通常ならば関数を使った暗黙的な変換を要求していたものであり、そして、ユーザが正しい引数型を持つ関数を明示的に定義した場合、パーサはこの新しい関数を使い、古い関数を使用した暗黙的な変換を行わないようにしなければなりません。