CREATE CAST (sourcetype AS targettype)
WITH FUNCTION funcname (argtypes)
[ AS ASSIGNMENT | AS IMPLICIT ]
CREATE CAST (sourcetype AS targettype)
WITHOUT FUNCTION
[ AS ASSIGNMENT | AS IMPLICIT ]CREATE CASTを使用すると、新しいキャストを定義できます。 キャストは、2つのデータ型間の変換処理方法を指定するものです。 以下に例を示します。
SELECT CAST(42 AS float8);
この文を実行すると、事前に指定された関数（この場合float8(int4)）が呼び出され、整数定数42がfloat8型に変換されます （適切なキャストが定義されていない場合、変換処理は失敗します）。
2つのデータ型をバイナリ互換性とすることができます。 この場合は、関数を呼び出さなくても、"自由に"お互いのデータ型に変換することができます。 ただし、対応する値は、同じ内部表現を使用している必要があります。 例えば、データ型textとvarcharには、バイナリ互換性があります。
デフォルトでは、キャストは明示的なキャスト要求があった場合のみ発生します。 明示的なキャスト要求の構文は、CAST(x AS typename)、もしくは、x::typenameです。
キャストにAS ASSIGNMENTオプションを付けると、対象データ型の列に代入する際、暗黙的にそのキャストを発生させるように設定できます。 例えば、foo.f1がtext型の列であるとします。
INSERT INTO foo (f1) VALUES (42);
integer型をtext型に変換するキャストにAS ASSIGNMENTオプションが付けられていれば、上記のSQL文が実行できます。 しかし、AS ASSIGNMENTオプションが付いていなければ、実行できません （一般的に、この種のキャストは代入キャストと呼ばれています）。
キャストにAS IMPLICITオプションを付けると、代入の場合だけでなく、式の中にある場合でも、全てのコンテキストで暗黙的にそのキャストを呼び出すように設定できます。 （一般的に、この種のキャストは暗黙キャストと呼ばれています。） 例えば次のような問い合わせを考えてみます。
SELECT 2 + 4.0;
パーサはまず定数にそれぞれintegerとnumericであると印を付けます。 システムカタログには、integer + numericという演算子はありませんが、numeric + numericという演算子は存在します。 したがって、integerからnumericへのキャストが利用可能であり、そのキャストにAS IMPLICITが付いていればこの問い合わせは成功します（実際このようになっています）。 パーサは暗黙的なキャストを行い、問い合わせをあたかも次のように記載されたものとして解決します。
SELECT CAST ( 2 AS numeric ) + 4.0;
ここで、カタログはまたnumericからintegerへのキャストも提供しています。 もしこのキャストにAS IMPLICITが付いていたら（実際は付いていません）、パーサは上のように解釈するか、それとも、numeric定数をintegerにキャストし、integer + integerという演算子を適用するかを選択しなければなりません。 どちらがより良いかという知見がなければ、選択をあきらめ、問い合わせがあいまいであると宣告します。 2つのキャストの内1つのみが暗黙的であるという事実が、パーサに、numericとintegerが混在する式をnumericとして扱うという適切な解決方法を知らせる方法です。 これに関する組み込まれた知見は存在しません。
暗黙キャストは、多用しない方が賢明です。 暗黙的キャストを使用し過ぎると、PostgreSQLがコマンドを思わぬ意味に解釈してしまう原因になります。 また、複数の解釈が可能なため、コマンドをまったく解読できなくなってしまう可能性もあります。 経験的には、2つのデータ型が同一の一般的なデータ型のカテゴリに属しており、変換によって情報が保持される場合のみ、暗黙キャストを呼び出し可能にするのが良い方法と思われます。 例えば、int2型からint4型へのキャストは、暗黙キャストにするのが妥当ですが、float8型からint4型へのキャストは、代入キャストのみにすべきと思われます。 text型からint4型への変換のような、カテゴリを越えるデータ型のキャストは、明示的にのみ使用するのが適切です。
キャストを作成するには、変換元または変換先のデータ型を所有している必要があります。 また、バイナリ互換性を持つキャストを作成できるのは、スーパーユーザのみです （バイナリ互換性があるキャスト変換を誤って使用するとサーバがクラッシュしてしまう可能性が高いことから、この制限が付けられました）。
キャストする変換元のデータ型の名前です。
キャストする変換先のデータ型の名前です。
この関数はキャストを実行するために使用します。 関数名はスキーマ修飾することができます。 スキーマ修飾されていない場合、関数はスキーマ検索パスから検索されます。 関数の結果のデータ型は、キャストの変換先のデータ型と一致する必要があります。 引数については後で説明します。
変換元データ型と変換先データ型の間に、バイナリ互換性があることを示します。 この場合、キャストを実行するのに関数は必要ありません。
代入コンテキストで、暗黙的にキャストを呼び出せることを示します。
任意のコンテキストで、暗黙的にキャストを呼び出せることを示します。
キャストを実装する関数は1〜3個の引数を取ることができます。 1番目の引数型はキャストの変換元データ型と同一でなければなりません。 2番目の引数（もしあれば）は、integer型でなければなりません。変換先の型に関連付けられた型修飾子を指定します。 型修飾子がない場合は-1を指定します。 3番目の引数（もしあれば）は、boolean型でなければなりません。キャストが明示的なキャストであればtrueを、それ以外であればfalseを指定します （奇妙な話ですが、SQL仕様では、明示的キャストと暗黙的キャストとの間で異なる振舞いを要求する場合があります。 この引数はそのようなキャストを実装しなければならない関数用に提供されています。 独自のデータ型をこの流儀に従うように設計することは勧められません）。
通常、キャストにおける変換元データ型と変換先データ型は異なる必要があります。 しかし、2つ以上の引数を持つ関数でキャストを実装した場合は、変換元と変換先とで同一のデータ型を持つキャストを宣言することができます。 これは、システムカタログにおいて型固有の長さ強制関数を表現するために使用されています。 このように指定された関数は、型の値を強制的に2番目の引数で与えられた型修飾子の値にするために使用されます （文法上、型修飾子を持つのは特定の組み込みデータ型のみなので、この機能は変換先のデータ型がユーザ定義のものである場合には役に立ちません。 ここでは、説明を完全にするために言及しています）。
変換元と変換先のデータ型が異なるキャストにおいて複数の引数を取る関数は、あるデータ型から他のデータ型への変換と長さの強制を1つの操作にまとめたものを表します。 引数を1つしか取らない場合は、型修飾子を使用して型を強制するために、データ型間の変換と修飾子の適用という2つの操作が必要となります。
ユーザ定義のキャストを削除するには、DROP CASTを使用してください。
データ型を双方向に変更可能にするには、双方向のキャストを明示的に宣言する必要があることに注意してください。
ユーザ定義型と標準文字列型（text、varchar、char(n)）との間のキャストを作成することは、通常必要ありません。 PostgreSQLは自動的に、他の型の出力関数を呼び出して文字列型へのキャストを扱います。 また反対に、文字列型からのキャストを他の型の入力関数を呼び出して扱います。 こうした自動的に提供されるキャストは入出力変換キャストと呼ばれます。 文字列型への入出力変換キャストは代入キャストとして扱われますが、文字列型からの入出力変換キャストは明示的なキャストのみです。 この振舞いは独自のキャストを宣言して入出力変換キャストを置き換えることで変更することができます。 しかし、通常このようにするのは、この変換を標準の代入のみまたは明示的のみの設定よりもより呼び出しやすくしたい場合に限られます。 他にも、型の入出力関数と異なる動作で変換したいという理由もあるかもしれません。 しかし、これは非常に驚かされるものであり、そうすべきかどうか熟考すべきです。 （組み込み型のごく一部は実際変換用に異なった振舞いをしますが、ほとんどは標準SQLの仕様のためのものです。）
PostgreSQL 7.3より前のバージョンでは、データ型と同じ名前を持ち、そのデータ型を返し、異なるデータ型の引数を1つ取る関数は、自動的にキャスト関数とみなされていました。 この慣習は、スキーマを導入し、システムカタログでバイナリ互換性によるキャストを実現可能にしたことにより、廃止されました。 組み込みキャスト関数は、まだこの命名規則に従っています。 しかし、他のキャスト同様、pg_castシステムカタログにキャストとして示されている必要があります。
必須ではありませんが、キャストを実装する関数には変換先のデータ型の名前を付けるという以前からの慣習に従っておくことを推奨します。 多くのユーザはtypename(x)という関数スタイルの記法でデータ型のキャストを行っています。 この記法は、キャストを実装している関数の呼び出しに他なりません。 キャストとして特別に扱っているわけではないのです。 ユーザが作成した変換関数の名前がこの慣習に従っていないと、他のユーザがとまどうことになります。 PostgreSQLは引数として異なる型を取る同じ名前の関数をオーバーロードすることができるので、様々な型から特定の変換先型への変換関数の名前を全て変換先の型名にしても特に問題は発生しません。
注意: 実際のところ、先ほどの段落は単純化しすぎたものです。 関数呼び出し式が実際の関数と一致しない状態でキャスト要求として扱われる状況が2つ存在します。 関数呼び出しname(x)が実際の関数に正確に一致せず、nameがデータ型の名前であり、pg_castがxの型からその型へのバイナリ互換のキャストを提供する場合、この呼び出しはバイナリ互換キャストとして処理されます。 この例外は、実際の関数が存在しなくても、関数のような構文でバイナリ互換キャストを呼び出すことができるように作成されました。 同様に、pg_castに項目がないが、文字列型との間のキャストが存在する場合、この呼び出しは入出力変換キャストとして処理されます。 この例外により関数のような構文で入出力変換キャストができるようになります。
関数int4(bigint)を使用したbigint型からint4型へのキャストを作成します。
CREATE CAST (bigint AS int4) WITH FUNCTION int4(bigint);
（このキャストは、システムに既に定義されています。）