CREATE TYPE

複合型

CREATE TYPEの最初の構文を使用すると、複合型を作成できます。 複合型は、列名およびデータ型のリストにより指定されます。 これは、本質的にはテーブルの行型と同じです。 しかし、型を定義するだけであれば、CREATE TYPEを使用することで、実際のテーブルを作成する必要をなくすことができます。 スタンドアロンの複合型は、関数の引数や戻り値の型として使用すると有用です。

列挙型

CREATE TYPEの3つ目の構文を使用すると、項8.7で説明する列挙型（enum）を作成します。 列挙型は、1つ以上の引用符付きのラベルのリストを取ります。 ラベルはNAMEDATALEN（PostgreSQLを標準で構築した場合は64）バイトよりも少ない長さでなければなりません。

基本型

CREATE TYPEの3つ目の構文を使用すると、基本型（スカラ型）を新しく作成できます。 パラメータは、上述の順番である必要はなく、任意の順番で指定することができます。 型を定義する前に、（CREATE FUNCTIONを用いて）2つ以上の関数を登録しておく必要があります。 サポート関数であるinput_functionとoutput_functionは必須です。 receive_function関数、send_function関数、type_modifier_input_function関数、type_modifier_output_function関数、およびanalyze_function関数は省略可能です。 通常、これらの関数は、C言語やその他の低レベル言語で作成されなければなりません。

input_functionは、型のテキストによる外部表現を内部表現形式に変換するものであり、その型用に定義される演算子や関数で使用されます。 output_functionはこの逆の変換を行うものです。 入力関数は、1つのcstring型の引数、あるいは、cstring型、oid型、integer型という3つの引数を取るように宣言されます。 最初の引数にはC文字列の入力テキスト、2番目には型自体のOID（配列型の場合は例外で要素の型のOIDとなります）、3番目は、判明していれば対象列のtypmodを渡します （不明な場合は-1を渡します）。 この入力関数では、データ型自身の値を返さなければなりません。 通常入力関数はSTRICTとして宣言しなければなりません。 そうしないと、NULLという入力値を読み取った時、NULLという最初のパラメータを持って呼び出されます。 この場合でも関数はNULLを返さなければなりません。 さもなくばエラーになります。 （こうした状況はほとんどの場合、ドメイン入力関数をサポートすることを意図しています。ドメイン入力関数ではNULL入力を拒絶する可能性があります。） 出力関数は、新しいデータ型の引数を1つ取るように宣言しなければなりません。 出力関数は、cstring型を返さなければなりません。 出力関数はNULL値に対して呼び出されることはありません。

receive_functionでは、型のバイナリによる外部表現を内部表現に変換します。この関数は省略可能です。 この関数が与えられない場合、この型ではバイナリ入力を行うことができません。 バイナリ表現の方法は、適度な移植性を保ちつつ、内部表現への変換コストが小さくなるよう選択すべきです （例えば標準の整数データ型は、外部バイナリ表現としてはネットワークバイトオーダを使用し、内部表現ではマシン固有のバイトオーダを使用します）。 この受信関数では、値が有効かどうかを判定するための適切な検査を行わなければなりません。 受信関数は、internal型の引数1つ、または、internal型とoid、integer型の3つの引数を取るように宣言されます。 最初の引数は受信したバイト文字列を保持するStringInfoバッファへのポインタ、省略可能な引数は、入力関数の説明と同じです。 そして、データ型自体の値を返す必要があります 通常受信関数はSTRICTとして宣言しなければなりません。 そうしないと、NULLという入力値を読み取った時、NULLという最初のパラメータを持って呼び出されます。 この場合でも関数はNULLを返さなければなりません。 さもなくばエラーになります。 （こうした状況はほとんどの場合、ドメイン受信関数をサポートすることを意図しています。ドメイン受信関数ではNULL入力を拒絶する可能性があります。） 同様に、send_functionは、内部表現からバイナリによる外部表現に変換します。この関数も省略可能です。 この関数が与えられない場合、この型ではバイナリ出力を行うことができません。 この送信関数は、新しいデータ型の引数1つを取るように宣言しなければなりません。 送信関数はbytea型を返さなければなりません。 送信関数はNULL値に対して呼び出されません。

ここで、新しいデータ型を作成する前に入力関数と出力関数を作成する必要があるのに、どのようにしてそれらの関数で新しいデータ型を戻り値や入力として宣言できるのか、疑問に思うかもしれません。 その答えは、まず型が最初にシェル型として定義されます。 この型はプレースホルダ型であり、名称と所有者以外の属性を持ちません。 これは、他にパラメータを持たないCREATE TYPE nameコマンドを発行することで行われます。 この後、入出力関数をこのシェル型を参照するように定義することができます。 最後に完全な定義を持ったCREATE TYPEによって、シェル型の項目が完全かつ有効な型定義に置き換わり、新しい型を普通に使用することができるようになります。

type_modifier_input_functionとtype_modifier_output_functionは省略可能ですが、型が修正子をサポートする場合は必要です。 修正子とは、char(5)やnumeric(30,2)などの省略可能な型宣言に付与される制約です。 PostgreSQLでは、ユーザ定義型が1つ以上の整数定数または識別子を修正子として取ることができます。 しかし、この情報はシステムカタログに格納される時に単一非負の整数にまとめられるものでなければなりません。 type_modifier_input_functionには、cstring型配列の形で宣言された修正子が渡されます。 その値について妥当性を検査しなければなりません（不当な場合はエラーとします）。 そして、正しい場合は、"typmod"列として格納される、単一非負のinteger値を返さなければなりません。 型がtype_modifier_input_functionを持たない場合、型修正子は拒否されます。 type_modifier_output_functionは内部的な整数typmod値をユーザ側の表示に合わせて変換します。 この関数は型名に付与する正確な文字列となるcstring値を返さなければなりません。 たとえばnumeric用の関数では(30,2)を返すかもしれません。 デフォルトの表示用書式が保管されたtypmod整数値を括弧で括ったものと一致している場合は、type_modifier_output_functionを省略することができます。

analyze_functionは、このデータ型の列に対する、型固有の統計情報の収集を行います。この関数は省略可能です。 デフォルトでは、その型用のデフォルトのB-tree演算子クラスがあれば、ANALYZEは型の"等価"演算子と"小なり"演算子を使用して統計情報を集めようと試みます。 非スカラ型には、この振舞いはあまり適していません。 そのため、独自の解析関数を指定すると、この振舞いを上書きすることができます。 この解析関数は、internal型の引数を1つ取り、戻り値としてbooleanを返すように宣言する必要があります。 解析関数用のAPIの詳細は、src/include/commands/vacuum.hにあります。

新しい型の内部表現の詳細を理解しなければならないのは、これらのI/O関数とその型に関連して動作するユーザ定義の関数のみですが、内部表現には、PostgreSQLに対し宣言しなければならない複数の属性値があります。 属性の中で最も重要なものはinternallengthです。 基本データ型は、internallengthに正の整数を指定して固定長として作成するだけでなく、internallengthにVARIABLEと設定し可変長として作成することもできます （内部的には、これはtyplenを-1に設定することで表現されます）。 全ての可変長型の内部表現は、型の値の全長を示す4バイトの整数値から始まらなければなりません。

PASSEDBYVALUEフラグは、このデータ型の値が参照ではなく値によって渡されることを示します。このフラグは省略可能です。 Datum型のサイズ（ほとんどのマシンでは4バイトだが、まれに8バイト）よりも長い内部表現の型は値で渡すことができません。

alignmentパラメータは、そのデータ型の格納の際に整列が必要であることを示します。 設定可能な値は、1、2、4、8バイト境界での整列と同じです。 可変長型の位置配置は最低でも4を持たなければならないことに注意してください。 最初の要素としてint4を持たなければならないからです。

storageパラメータを使用することで、可変長データ型を格納する際の戦略を選択することができます （固定長の型にはplainのみが使用できます）。 plainを指定すると、その型のデータは常にインラインで格納され、圧縮されません。 extendedを指定すると、システムはまず長いデータ値を圧縮しようとし、それでもまだ長過ぎる場合は値をメインテーブルの行から削除して移動します。 externalはメインテーブルから値を削除して移動することを許しますが、システムはデータを圧縮しようとしません。 mainはデータの圧縮を許し、できるだけ値をメインテーブルから削除しないようにします （行を収めるために他に方法がない場合にはメインテーブルから削除されてしまう可能性がありますが、extendedやexternalが指定されたアイテムよりも優先してメインテーブルに残されます）。

ユーザがそのデータ型の列のデフォルトをNULL以外にしたい場合は、デフォルト値を指定することができます。 デフォルト値はDEFAULTキーワードで指定してください （この方法で指定されたデフォルト値は、特定の列に付与された、明示的なDEFAULT句によって上書きされる可能性があります）。

データ型が配列であることを示すには、ELEMENTキーワードを使用して配列要素の型を指定してください。 例えば、4バイト整数（int4）の配列を定義するには、ELEMENT = int4と指定してください。 詳細は後述の配列型で説明します。

この型による配列の外部形式における値間の区切り文字を示すために、delimiterで特定の文字を設定することができます。 デフォルトの区切り文字はカンマ（','）です。 この区切り文字は、配列要素の型に関係するものであり、配列型自体に関係するものでないことに注意してください。

配列型

ユーザ定義型が作成されると、PostgreSQLは、自動的に、基本型名の前にアンダースコアを付け、必要に応じてNAMEDATALEN長より短くなるように切り詰められた名前を持つ、関連する配列型を作成します。 （こうして付けられた名前が既存の型名と競合する場合、競合する名称がなくなるまでこの処理が繰り返されます。） この暗黙的に作成される配列型は可変長で、組み込み入出力関数array_inとarray_outを使用します。 配列型はその要素となる型の所有者とスキーマのなんらかの変更に追従し、また、要素となる型が削除された場合に削除されます。

理論的に考えると、「システムが自動的に配列型を正しく作成するのであれば、ELEMENTオプションはどうして存在するのだろう」と不思議に思うでしょう。 ELEMENTが意味を持つ、唯一の場合は次のような条件を満たす固定長の型を作成する時です。 その条件とは、内部的に大量の同一の要素からなる配列となっていること、その配列に対して添字を指定して直接アクセスできること、加えて、今後作成する型全体に対する操作がどのようなものであっても、それらから直接アクセスできることです。 例えば、point型では、その構成要素である2つの浮動小数点にpoint[0]およびpoint[1]という方法でアクセスすることができます。 この機能は、その内部形式が同一の固定長フィールドの正確な並びである、固定長の型でのみ動作することに注意してください。 添字による指定が可能な可変長型は、array_inとarray_outを使用して、一般化された内部表現を持つ必要があります。 歴史的な理由（明らかに間違いなのですが、変更するには遅すぎたため）により、固定長配列型への要素番号指定は0から始まり、可変長配列の場合は1から始まります。