.\\" auto-generated by docbook2man-spec $Revision: 1.2 $
.TH "CREATE CAST" "" "2005-01-19" "SQL - 言語" "SQL コマンド"
.SH NAME
CREATE CAST \- 新しいキャストの定義

.SH SYNOPSIS
.sp
.nf
CREATE CAST (\fIsourcetype\fR AS \fItargettype\fR)
    WITH FUNCTION \fIfuncname\fR (\fIargtypes\fR)
    [ AS ASSIGNMENT | AS IMPLICIT ]

CREATE CAST (\fIsourcetype\fR AS \fItargettype\fR)
    WITHOUT FUNCTION
    [ AS ASSIGNMENT | AS IMPLICIT ]
.sp
.fi
.SH "説明"
.PP
\fBCREATE CAST\fRを使用すると、新しいキャストを定義できます。
キャストにより、2つのデータ型間の変換処理方法を指定します。
以下に例を示します。
.sp
.nf
SELECT CAST(42 AS text);
.sp
.fi
この処理を実行すると、事前に指定された関数、この場合text(int4)を呼び出し、整数定数42を\fBtext\fRデータ型に変換します。 
(適切なキャストが定義されていない場合、変換処理は失敗します。)
.PP
2つのデータ型は、\fIバイナリ互換性がある\fR場合があります。
つまり、``自由に''関数を呼び出すことなくお互いのデータ型に変換することができます。
この場合、対応する値は、同じ内部表現を使用している必要があります。
例えば、データ型\fBtext\fRおよび\fBvarchar\fRは、バイナリ互換性があります。 
.PP
デフォルトでは、キャストは明示的なキャスト要求があった場合のみ呼び出し可能です。
明示的なキャストの構文とは、CAST(\fIx\fR AS \fItypename\fR)、もしくは、\fIx\fR::\fItypename\fRです。
.PP
キャストにAS ASSIGNMENTオプションを付けると、対象データ型の列に代入する際、暗黙的にそのキャストを呼び出すように設定できます。
例えば、foo.f1が\fBtext\fR型の列であるとします。
.sp
.nf
INSERT INTO foo (f1) VALUES (42);
.sp
.fi
\fBinteger\fR型から\fBtext\fR型へ変換するキャストにAS ASSIGNMENTオプションが付けられていれば、上記のSQL文は実行可能です。
オプションが付いていなければ、実行できません。 
(一般的に、この種のキャストは\fI代入キャスト\fRと呼ばれています。 )
.PP
キャストにAS IMPLICITオプションを付けると、代入でも、もしくは式の中にあるものでも、全てのコンテキストで暗黙的にそのキャストを呼び出すように設定できます。
以下の例を参照してください。
||は\fBtext\fR型の引数を受け取りますので、
.sp
.nf
SELECT 'The time is ' || now();
.sp
.fi
というSQL文は、\fBtimestamp\fR型から\fBtext\fR型へ変換するキャストにAS IMPLICITオプションが付けられている場合のみ実行可能です。
オプションが付いていなければ、以下のように明示的にキャストを記述する必要があります。
.sp
.nf
SELECT 'The time is ' || CAST(now() AS text);
.sp
.fi
(一般的に、この種のキャストは\fI暗黙キャスト\fRと呼ばれています。 )
.PP
暗黙キャストは、多用しない方が賢明です。
暗黙的キャストを使用しすぎると、PostgreSQLがコマンドを思わぬ意味に解釈してしまう原因になります。
もしくは、複数の解釈が可能なため、コマンドを全く解読できなくなってしまう可能性もあります。
経験的には、同じ一般的なデータ型カテゴリのデータ型間で、情報を保持する変換でのみ、暗黙キャストを呼び出し可能にするのが良い方法と思われます。
例えば、\fBint2\fR型から\fBint4\fR型へのキャストは、暗黙キャストにするのが妥当ですが、\fBfloat8\fR型から\fBint4\fR型へのキャストは、おそらく代入キャストのみとすべきでしょう。
\fBtext\fR型から\fBint4\fR型への変換のような、カテゴリを越えるデータ型のキャストは、明示的にのみ使用するのが適切です。
.PP
キャストを作成可能にするには、変換元または変換先のデータ型を所有している必要があります。
また、バイナリ互換性があるキャストを作成するには、スーパーユーザである必要があります
(バイナリ互換性があるキャスト変換を誤って使用するとサーバがクラッシュしてしまう可能性が高いことから、この制限が付けられました)。
.SH "パラメータ"
.TP
\fB\fIsourcetype\fB\fR
キャストする変換元のデータ型の名前です。
.TP
\fB\fItargettype\fB\fR
キャストする変換先のデータ型の名前です。
.TP
\fB\fIfuncname\fB(\fIargtypes\fB)\fR
この関数は、キャストを実行するために使用します。
関数名は、スキーマ修飾することができます。
スキーマ修飾されていない場合、関数はスキーマ検索パスから検索されます。
関数の結果のデータ型はキャストの変換先のデータ型と一致する必要があります。
引数については後で説明します。
.TP
\fBWITHOUT FUNCTION\fR
変換元データ型および変換先データ型は、バイナリ互換性があることを示します。
従って、キャストを実行するのに関数は必要ありません。
.TP
\fBAS ASSIGNMENT\fR
代入コンテキストで、暗黙的にキャストを呼び出すことができることを示します。
.TP
\fBAS IMPLICIT\fR
任意のコンテキストで、暗黙的にキャストを呼び出すことができることを示します。
.PP
キャストを実装する関数は1から3つの引数を取ることができます。
1番目の引数型はキャストの変換元データ型と同一でなければなりません。
2番目の引数は、もしあれば、\fBinteger\fR型でなければならず、変換先の型に関連付いた型修飾子を受け取ります。
型修飾子がない場合は-1を受け取ります。
3番目の引数は、もしあれば、\fBboolean\fR型でなければならず、キャストが明示的なキャストであればtrueを、それ以外であればfalseを受け取ります。
(奇妙ですが、SQL仕様では、明示的キャストと暗黙的キャストとの間で異なる振舞いを要求する場合があります。
この引数はそうした状況を実装しなければならない関数用に提供されるものです。
独自のデータ型をこの流儀に従うように設計することは勧められません。)
.PP
.PP
普通、キャストは異なる変換元と変換先のデータ型を持たなければなりません。
しかし、2つ以上の引数をもつ関数でキャストを実装した場合は、変換元と変換先とで同一のデータ型を持つキャストを宣言することができます。
これは、システムカタログにおいて型固有の長さ強制関数を表現するために使用されてます。
指名された関数は、2番目の引数で与えられた型修飾子の値で型の値を強制するために使用されます。
(文法上、特定の組み込みデータ型のみが型修飾子を持つことができますので、この機能は変換先がユーザ定義のデータ型の場合には役に立ちません。
説明を完全にするためにここで記述しています。)
.PP
.PP
変換元と変換先のデータ型が異なるキャストで、その関数が複数の引数を取る場合、それは、あるデータ型から他のデータ型への変換と長さの強制を1つの操作にまとめたものであることを表します。
こうした項目がないと、型修飾子を使用する型の強制は、最初にデータ型間の変換、次に修飾子の適用という2つの操作が必要となります。
.PP
.SH "注釈"
.PP
ユーザ定義のキャストを削除するには、DROP CAST [\fBdrop_cast\fR(l)]を使用してください。
.PP
データ型を双方向に変更可能にするには、双方向のキャストを明示的に宣言する必要があることに注意してください。
.PP
PostgreSQL 7.3より前のバージョンでは、あるデータ型と同じ名前で、そのデータ型を返し、異なるデータ型の引数を1つ取る関数は、自動的にキャスト関数とされていました。
この慣習は、スキーマを導入し、システムカタログでバイナリ互換性があるキャストを表現可能になったことにより、禁止されました。 
組み込みキャスト関数は、まだこの命名規則に従っています。
しかし、同様にpg_castシステムカタログでキャストとして示される必要があります。 
.PP
必要ではありませんが、キャストを実装する関数を変換先のデータ型に因んで命名するという、この古い慣習に従い続けることを推奨します。
多くのユーザは関数様式の記法、つまり\fItypename\fR(\fIx\fR)、を使用してデータ型のキャストができるということを使用しています。
この記法はキャストを実装する関数を呼び出していることに他なりません。
特にキャストとして扱っているわけではないのです。
独自の変換関数の名前がこの慣習に従っていないと、他のユーザはとまどうことになります。
PostgreSQLは異なる引数型で同じ名前の関数をオーバーロードすることができますので、様々な型からある変換先型への複数の変換関数を、全て変換先の型名を使用して作成することは難しくありません。
.sp
.RS
.B "Note:"
上の段落には小さな嘘があります。
明確な関数呼び出しの意味解決のために\fBpg_cast\fRが使用される場合があることです。
関数呼び出し\fIname\fR(\fIx\fR)が実際の関数に一致せず、\fIname\fRがデータ型の名前であり、\fBpg_cast\fRが\fIx\fRの型からその型へのキャストがバイナリ互換であることを示していた場合、この呼び出しは明示的キャストとして呼び出されます。
この例外は、バイナリ互換キャストを、実際の関数がなかったとしても、関数のような構文で呼び出すことができるように作成されました。
.RE
.sp
.SH "例"
.PP
関数int4(text)を使用した\fBtext\fR型から\fBint4\fR型へのキャストを作成します。
.sp
.nf
CREATE CAST (text AS int4) WITH FUNCTION int4(text);
.sp
.fi
(このキャストは、システムにすでに事前定義されています。)
.SH "互換性"
.PP
\fBCREATE CAST\fRは、SQL:1999ではバイナリ互換性があるデータ型や実装する関数への多くの引数についての規定を行わない点を除き、SQL:1999に準拠しています。
AS IMPLICITも、PostgreSQLの拡張です。
.SH "関連項目"
.PP
CREATE FUNCTION [\fBcreate_function\fR(l)],
CREATE TYPE [\fBcreate_type\fR(l)],
DROP CAST [\fBdrop_cast\fR(l)]
