3.2 データ型

以下の表に組み込みの汎用データ型を示します。

表 3-1 データ型

以下の章では各データ型を詳しく説明します。

3.2.1 数値データ型

数値データ型には4バイト整数と、4、8バイト浮動小数点および精度設定が可能な数があります。以下の表に使用可能な型を列挙します。

表3-2 数値データ型

次節でデータ型について詳しく説明します。

3.2.1.1 整数データ型

INTEGER型は各種範囲の整数、つまり小数点以下の端数がない数を保持します。許容範囲から外れた値を保存しようとするとエラーになります。

3.2.1.2 任意の精度を持つ数

NUMBER型は、最大1000桁の精度で数値を格納でき、正確な計算を行えます。通貨金額やその他正確性が求められる数量を保存する時は特に、この型を推奨します。とは言っても、NUMBERの値に対する算術演算の動作は次節で説明する浮動小数点データ型に比較し非常に遅くなります。

この後の説明では、次の用語を使用します。NUMBERの位取りとは、小数点の右側の小数点以下の桁数をいいます。NUMBERの精度とは数字全体の有効桁数です。すなわち、小数点をはさんでいる両側の桁数の合計です。そのため、23.5141という数値の精度は6で位取りは4となります。整数の位取りは、ゼロであるとみなすことができます。

NUMBER型の数値の最大精度と最大位取りはともに設定することができます。列のデータ型をNUMBERと宣言するには次の構文を使います。

NUMBER(precision, scale)

精度は正数、位取りは0もしくは正数でなければなりません。他に

NUMBER(precision)

は位取りが0であることを選択します。

NUMBER

上記のように精度または位取りの指定がない場合、実装されている限界の精度まで、いかなる精度あるいは位取りの値も格納できる列が作られます。この類の列はいかなる特定の位取りに対しても入力値を強要しませんが、宣言された位取りを持つNUMBER列は入力値にその位取りを強要します（標準SQLはデフォルトとして位取り0を要求していて、整数に対する厳密性を強制しています。もし移植性を心配するなら、常に精度と位取りを明示的に設定してください）。

格納される値の精度もしくは位取りが宣言された列の精度もしくは位取りより大きかった場合、システムは値を丸めようとします。しかし、宣言された精度と位取りを満たすように値を丸めることができない場合はエラーとなります。

3.2.1.3 浮動小数点データ型

REALとDOUBLE PRECISION型は不正確な可変精度の数値データ型です。実際にはこれらのデータ型は、使用しているプロセッサ、オペレーティングシステムおよびコンパイラがサポートしていれば、通常は（それぞれ単精度および倍精度の）バイナリ浮動小数点演算用のIEEE規格754の実装です。

不正確というのは、内部形式に正確に変換されずに近似値として保存される値もあるということです。ですから、保存しようとする値と保存された値を戻して表示した場合に多少の差異が認められます。これらのエラーを管理し計算によって補正をどうするかは、数学とコンピュータ科学の全般に関わることで、以下の点を除きこれ以上は触れません。

（金銭のような）正確な記録と計算が必要な時は代わりにNUMBER型を使用してください。

これらのデータ型で何か重要な件に対し複雑な計算を必要とする時、特に（無限大やアンダーフローのような）境界線におけるある種の振舞いについて信頼を置かなければならないのであれば、実装を注意深く検証しなければなりません。

2つの浮動小数点値が等価であるのかどうかの比較は予想通りに行く時もあれば行かない時もあります。

ほとんどのプラットフォームではREALは最低6桁の精度を持った少なくとも1E-37から1E+37の範囲の値です。DOUBLE PRECISIONは通常最低15桁の精度を持ったおよそ1E-307から1E+308の範囲の値です。大き過ぎたり小さ過ぎる値はエラーの原因となります。入力値の精度が高過ぎる場合は丸められることがあります。ゼロに限りなく近い値で、しかもゼロとは区別されているようにみなされない数値はアンダーフローエラーを引き起こします。

また、Postgres Plusでは不正確な数値型を規定する標準SQLのFLOATとFLOAT(p)をサポートしています。ここで、pは2進数の桁数で最低許可する精度を指定します。Postgres PlusはFLOAT(1)からFLOAT(24)までをREALを指定したものとして扱い、FLOAT(25)からFLOAT(53)までをDOUBLE PRECISIONを指定したものとして扱います。許容範囲外のpの値はエラーになります。精度指定のないFLOATはDOUBLE PRECISIONとして解釈されます。

3.2.2 文字型

以下の表は、Postgres Plusで使用可能な汎用文字型を示したものです。

表3-3文字型

2つの主要な文字データ型はCHAR(n)とVARCHAR2(n)です。ここでnは正の整数です。これらのデータ型は2つともn文字長までの文字列を保存できます。CHAR型でnが省略された場合、デフォルト値は1です。超過している文字が全て空白の場合を除いて、上限を越えた文字列をこれらの型の列に保存しようとするとエラーになります。超過している文字が全て空白の場合は長さの限界で切り捨てられます。もし宣言された上限よりも文字列が短い時はCHARの値は空白で埋められ、VARCHAR2の値は単にその短い文字列で保存されます。

明示的に値をVARCHAR2(n)またはCHAR(n)にキャストした場合、指定長を超えるとエラーなしでn文字まで切り詰められます。（これもまた標準SQLの仕様です。）

CHAR型の値は、指定長nになるまで物理的に空白で埋められ、そのまま格納、表示されます。しかし、追加された空白は意味的には重要でないものとして扱われます。最後の空白は、2つのCHAR型の値を比べる際には無視されます。また、CHAR型の値を他の文字列型に変換する際には除去されます。VARCHAR2型の値では、最後の空白は意味的に重要なものですので、注意してください。

3つ目の文字データ型はCLOBです。これは長い文字列を格納するために使用されます。上限を指定しないことを除いて、CLOBは意味的にVARCHAR2と同じです。一般的に、文字の長さがどのくらいになるか分からない場合、VARCHAR2ではなくCLOBを使用します。

CLOB型で格納できる文字列サイズは約1GBです。

これらの型のデータの保存に必要なサイズは、文字列が127バイト未満の場合は実際の文字列サイズに1バイトを、文字列が127バイト以上の場合は4バイトを加えたサイズになります。CHAR型ではパッド分が更に加わります。長い文字列はシステムで自動的に圧縮されますので、ディスク上の物理的必要容量は少なくなります。また、列の中で長い値はより短い値への高速アクセスに干渉しないように、バックグラウンドテーブルに格納されます。

データベースの文字セットは、テキストの値を格納する時に使用される文字セットを決定します。

3.2.3 バイナリ列データ型

BLOBデータ型はバイナリ列の格納を可能にします。

表3-4バイナリ列データ型

バイナリ列はオクテット（またはバイト）の連続です。バイナリ列が文字列と異なる点は次の2点です。1点目は、バイナリ列はゼロの値のオクテットと他の"表示できない"オクテット（通常32から126までの範囲外のオクテット）を格納できるということです。2点目は、バイナリ列を演算すると実際のバイトが処理されるのに対して、文字列のエンコードと処理はロケール設定に従うということです。

3.2.4 日付/時刻データ型

以下の日付/時刻データ型の説明は、テーブルを作成もしくは変更する時にedb_redwood_dateコンフィグレーションパラメータが真に設定されていることを前提とします。

Postgres Plusでは、以下の表に示されている日付/時刻データ型がサポートされています。

表3-5日付/時刻データ型

データ定義言語（DDL）のコマンド、CREATE TABLEもしくはALTER TABLEの中で列のデータ型としてDATEが使用されている場合、テーブル定義をデータベースに格納する時にDATEはTIMESTAMP(0)に変換されます。したがって、時刻も日付と一緒に列に格納されます。

SPL内の宣言部分で変数のデータ型として、プロシージャや関数でパラメータのデータ型として、もしくは関数の戻り値のデータ型として、DATEが使用されている場合、常にTIMESTAMP(0)に変換されます。したがって、時刻を処理できます。

TIMESTAMPでは秒フィールドに保有される値の小数点以下の桁数を指定する精度値であるオプションpを取ることができます。pの許容範囲は0から6までです。デフォルトでは6です。

TIMESTAMPの値が倍精度浮動小数点数として保存されている場合（現在のデフォルトです）、有効な精度は6より小さいかもしれません。TIMESTAMPの値は2000-01-01深夜を基準にした経過秒数として格納されます。マイクロ秒の精度は、2000-01-01から2、3年以内の日付では高いですが、その精度は日付が（2000-01-01から）離れるにつれて悪化します。TIMESTAMPの値が8バイト整数（コンパイル時にオプション指定）として格納される時にはマイクロ秒の精度は全ての範囲の値に関して有効です。しかし、8バイト整数のタイムスタンプでは、その日付の範囲が上述よりも制限され、4713 BCから294276 ADまでとなってしまいます。

3.2.4.1 日付/時刻の入力

日付と時刻の入力は、ISO 8601 SQL互換の書式、Oracleのデフォルト書式dd-MON-yy、その他の年月日を正確に表現する書式を受け付けます。しかしながら、間違った解釈になることを避けるためにTO_DATE関数を使用することを強く推奨します。第3.5.6章を参照してください。

テキスト文字列のように、日付や時刻リテラルは単一引用符で囲む必要があります。以下の標準SQLの構文も可能です。

type 'value'

typeはDATEもしくはTIMESTAMPのどちらかです。valueは日付/時刻の文字列です。

3.2.4.1.1 日付

以下の表は日付入力で可能な書式の一部を示しています。すべて、1999年1月8日です。

表 3-6 日付入力

日付の値はDATEもしくはTIMESTAMP型の列や変数に割り当てることができます。日付の値に時刻の値が追加されない場合、時、分、秒のフィールドにはゼロが設定されます。

3.2.4.1.2 時刻

以下の表はDATEもしくはTIMESTAMP型の時刻の例をいくつか示しています。

表 3-7 時刻入力

3.2.4.1.3 タイムスタンプ

TIMESTAMP型への有効な入力は、日付と時刻をセットにしたものからなります。日付部分は表表 3-6 日付入力日付入力に示した例のような書式になります。時刻部分は表表 3-7 時刻入力時刻入力に示した例のような書式になります。

以下はOracleのデフォルト書式の例です。

08-JAN-99 04:05:06

以下はISO 8601標準書式の例です。

1999-01-08 04:05:06

3.2.4.2 日付/時刻の出力

日付と時刻のデフォルトの出力書式は、Redwood date styleと呼ばれるOracle互換の書式（dd-MON-yy）もしくはISO 8601の書式（yyyy-mm-dd）のいずれかです。どちらになるかはデータベースへのアプリケーションのインターフェース次第です。Postgres Plus SQL InteractiveのようなJDBCを使用するアプリケーションでは、常にISO 8601書式の日付になります。PSQLのような他のアプリケーションでは、Oracle互換の書式の日付になります。

以下の表は、Oracle互換とISO 8601の2つの出力書式の例を示しています。

表3-8日付/時刻出力書式

3.2.4.3 内部データ

Postgres Plusはすべての日付と時刻の計算にユリウス日を使用しています。これは、1年を365.2425日であると仮定し、紀元前4713年から未来までのすべての日付を正確に予測や計算するという優れた特性を持っています。

3.2.5 論理値データ型

Postgres Plusでは、標準SQLのBOOLEAN型が提供されています。BOOLEANは"真"もしくは"偽"という2つしかない値のどちらかを取ることができます。第3の状態である"不明"はSQLのnull値で表現されます。

表3-9論理値データ型

"真"状態に対する有効なリテラル値はTRUEです。"偽"状態に対する有効なリテラル値はFALSEです。

注: BOOLEAN型はSPLプログラム内の変数宣言でのみ使用できます。テーブル内の列のデータ型の定義では使用できません。