複合型

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

複合型を作成するためには、すべての属性型に対してUSAGE権限を持たなければなりません。

列挙型

CREATE TYPEの2つ目の構文を使用すると、8.7で説明する列挙型（enum）を作成します。 列挙型は、引用符付きのラベルのリストを取ります。 ラベルはNAMEDATALEN（PostgreSQLの標準のビルドでは64バイト）バイトよりも少ない長さでなければなりません。 (ラベルのない列挙型を作成できますが、ALTER TYPEを使ってラベルを少なくとも1つ追加するまでは、そのような型は値を保持するのに使えません。)

範囲型

CREATE TYPEの三番目の構文は、8.17で説明する範囲型を新規に作成します。

範囲型のsubtypeは、関連する（範囲型の値を順序を決定するための）b-tree演算子クラスを持つ任意の型を取ることができます。 通常、派生元型のデフォルトのb-tree演算子クラスが順序を決定するために使用されます。 デフォルト以外の演算子クラスを使用するためには、subtype_opclassでその名前を指定してください。 派生元型が照合順序変更可能であり、範囲の順序付けでデフォルト以外の照合順序を使用したい場合は、collationオプションで使用したい照合順序を指定してください。

canonical関数(省略可能)は、定義する範囲型の引数を１つ取り、同じ型の値を返さなければなりません。 これは適切な時に範囲値を正規形式に変換するために使用されます。 詳細については8.17.8を参照してください。 canonical関数を作成することは多少厄介です、というのは、範囲型を定義できるようになる前に定義されている必要があるからです。 このためには、まず、名前と所有者以外の属性を持たないプレースホルダであるシェル型を作成しなければなりません。 これは、他にパラメータをつけずにCREATE TYPE nameを実行することで行われます。 その後、このシェル型を引数と結果として使用する関数を宣言することができます。 最後に同じ名前を用いて範囲型を宣言することができます。 これは自動的にシェル型の項目を有効な範囲型に置き換えます。

subtype_diff関数(省略可能)は、subtype型の２つの値を引数として取り、与えられた２つの値の差異を表すdouble precision型を返さなければなりません。 これは省略することができますが、提供することでその範囲型の列に対するGiSTインデックスの効率を大きく向上させることができます。 詳細については8.17.8を参照してください。

multirange_type_nameパラメータ(省略可能)は、対応する多重範囲型の名前を指定します。 指定されなければ、この名前は自動的に以下のように選ばれます。 範囲型の名前が部分文字列rangeを含んでいれば、多重範囲型の名前は、範囲型の名前における部分文字列rangeをmultirangeで置き換えることで作られます。 そうでなければ、多重範囲型の名前は範囲型の名前の末尾に_multirangeを追加することで作られます。

基本型

CREATE TYPEの４つ目の構文を使用すると、基本型（スカラ型）を新しく作成できます。 新しい基本型を作成するにはスーパーユーザでなければなりません。 （エラーがある型定義が混乱を招き、サーバがクラッシュすることすらあるため、この制限がなされました。）

パラメータは、上述の順番である必要はなく、任意の順番で指定することができ、多くは省略可能です。 型を定義する前に、（CREATE FUNCTIONを用いて）2つ以上の関数を登録しておく必要があります。 サポート関数であるinput_functionとoutput_functionは必須です。 receive_function関数、send_function関数、type_modifier_input_function関数、type_modifier_output_function関数、analyze_function関数、およびsubscript_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を他にパラメータをつけずに発行することで行われます。 この後、Cの入出力関数をこのシェル型を参照するように定義することができます。 最後に完全な定義を持ったCREATE TYPEによって、シェル型の項目が完全かつ有効な型定義に置き換わり、新しい型を普通に使用することができるようになります。

type_modifier_input_functionとtype_modifier_output_functionは必須ではありませんが、型が修飾子をサポートする場合は必要です。 修飾子とは、char(5)やnumeric(30,2)などの型宣言に付与されるオプションの制約です。 PostgreSQLでは、ユーザ定義型が1つ以上の整数定数または識別子を修飾子として取ることができます。 しかし、この情報はシステムカタログに格納される時に0以上の整数1つにまとめられるものでなければなりません。 type_modifier_input_functionには、cstring型配列の形で宣言された修飾子が渡されます。 その値について妥当性を検査しなければなりません（不当な場合はエラーとします）。 そして、正しい場合は、「typmod」列として格納される、0以上のinteger値を1つ返さなければなりません。 型が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にあります。

オプションのsubscript_functionは、SQLコマンド内で指定されたデータ型に添字をつけることを許可します。 この関数を指定することで、指定されたデータ型が「真の」配列型とみなされる訳ではありません。たとえば、ARRAY[]生成の結果型の候補にはなりません。 ですが、その型の値に添字をつけることが、そこからデータを取り出す自然な表記法であるなら、その意味を定義するのにsubscript_functionを書くことができます。 添字関数はinternal型の引数を1つ取り、添字を実装しているメソッド(関数)の構造体へのポインタであるinternalの結果を返すよう宣言しなければなりません。 添字関数の詳細なAPIはsrc/include/nodes/subscripting.hにあります。 src/backend/utils/adt/arraysubs.cにある配列の実装やcontrib/hstore/hstore_subs.cにあるより単純なコードを読むのも有用かもしれません。 追加の情報は以下のArray Typesにあります。

新しい型の内部表現の詳細を理解しなければならないのは、これらのI/O関数とその型に関連して動作するユーザ定義の関数のみですが、内部表現には、PostgreSQLに対し宣言しなければならない複数の属性値があります。 属性の中で最も重要なものはinternallengthです。 基本データ型は、internallengthに正の整数を指定して固定長として作成するだけでなく、internallengthにVARIABLEと設定し可変長として作成することもできます （内部的には、これはtyplenを-1に設定することで表現されます）。 全ての可変長型の内部表現は、型の値の全長を示す4バイトの整数値から始まらなければなりません。 （長さフィールドは多くの場合70.2に記述されているようにエンコードされており、それに直接アクセスすることは賢明ではないことに注意してください。）

オプションのPASSEDBYVALUEフラグは、このデータ型の値が参照ではなく値によって渡されることを示します。 値によって渡される型は固定長でなければならず、その内部表現はDatum型のサイズ（4バイトのマシンもあれば8バイトのマシンもあります）を超えてはいけません。

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

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

plainを除くすべてのstorageの値は、そのデータ型の関数が、70.2および38.13.1に記述されているようにtoastされた値を処理できることを暗示します。 その他の特定の値を指定するのは、TOAST可能なデータ型の列について、単にデフォルトのTOAST戦略を決めるだけです。 ユーザは個々の列についてALTER TABLE SET STORAGEを使って他の戦略を選択できます。

like_typeパラメータは、何らかの既存のデータ型から複製するという、データ型の基本表現プロパティを指定する、別の方法を提供します。 internallength、passedbyvalue、alignment、storageの値が指定された型から複製されます。 （通常は望ましくありませんが、LIKE句と一緒にこれらの値を指定することで、値を上書きすることも可能です。） 新しい型の低レベル実装にある流儀に従った既存の型を「移す」時に、この方法で表現を指定することが特に有用です。

categoryとpreferredパラメータは、あいまいな状況でどの暗黙的なキャストが適用されるかについての制御を補助するために使用することができます。 各データ型は単一のASCII文字で命名されるカテゴリに属しており、各型はそのカテゴリ内で「優先される（preferred）」か否かです。 オーバーロードされた関数または演算子の解決に、この規則が有用な場合には、パーサは優先される型へのキャストを優先します（ただし、同一のカテゴリ内の他の型からだけです）。 より詳細は第10章を参照してください。 他の型への、または、ほかの型からの暗黙的なキャストを持たない型では、これらの設定をデフォルトのままにしておくことで十分です。 しかし、暗黙的なキャストを持つ関連する型のグループでは、それらすべてを1つのカテゴリに属すものとし、「最も汎用的な」型の1つまたは2つをカテゴリ内で優先されるものとして選択することが有用となる場合が多くあります。 ユーザ定義型を、数値型や文字列型などの既存の組み込みカテゴリに追加する場合に、categoryパラメータは特に有用です。 しかし、完全にユーザ定義の新しい型カテゴリを作成することもできます。 そのようなカテゴリの命名には大文字以外の任意のASCII文字を選択してください。

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

データ型が固定長の配列型であることを示すには、ELEMENTキーワードを使用して配列要素の型を指定してください。 例えば、4バイト整数（int4）の配列を定義するには、ELEMENT = int4と指定してください。 より詳細は以下のArray Typesを参照してください。

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

論理型のcollatableパラメータ(省略可能)が真の場合、COLLATE句を使用することによって、型の列定義と式は照合順序情報を持つことができます。 照合順序情報を実際に使用するかどうかは、型に対する操作を行う関数実装に任されています。 照合順序を設定可能な型を作成することにより、これが自動的に行われることはありません。

配列型

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

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

SUBSCRIPTオプションを指定すると、たとえシステムが配列型とみなさない場合でも、データ型に添字をつけることができるようになります。 固定長の配列について述べた振舞いは、実はSUBSCRIPTハンドラ関数raw_array_subscript_handlerにより実装されており、固定長型に対してSUBSCRIPTを書かずにELEMENTを指定した場合には自動的に、この関数が使われます。

カスタムのSUBSCRIPT関数を指定した場合には、SUBSCRIPTハンドラ関数が何を返すべきか見つけるためにtypelemを調べる必要がない限り、ELEMENTを指定することは必要ではありません。 ELEMENTを指定すると、新しい型が要素型を含んでいる、すなわち要素型に何らかの形で物理的に依存しているとシステムが仮定することに注意してください。このため、例えば、依存する型の列があれば要素型の属性を変更することはできません。