他のバージョンの文書9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

Chapter 3. データ型

Table of Contents
3.1. 数値データ型
3.1.1. 整数データ型
3.1.2. 任意の精度を持つ数
3.1.3. 浮動小数点データ型
3.1.4. シリアルデータ型
3.2. 通貨データ型
3.3. 文字データ型
3.4. バイナリ列データ型
3.5. 日付/時刻データ型
3.5.1. 日付/時刻の入力
3.5.2. 日付/時刻出力
3.5.3. 時間帯
3.5.4. 内部形式
3.6. 論理値データ型
3.7. 幾何データ型
3.7.1. point(座標点)
3.7.2. lseg(線分)
3.7.3. box(矩形)
3.7.4. path データ型
3.7.5. polygon(多角形)
3.7.6. circle (円)
3.8. ネットワークアドレスデータ型
3.8.1. inet
3.8.2. cidr
3.8.3. inetcidr データ型の違い
3.8.4. macaddr
3.9. ビット列データ型

PostgreSQL にはユーザが使用可能な豊富なデータ型一式が始めから備なわっています。CREATE TYPE コマンドで PostgreSQL に対し新しいデータ型を追加できます。

Table 3-1 に標準の配付物に含まれる汎用データ型を示します。過去の資産の継承として PostgreSQL の内部で使用される名前が "エイリアス"の欄に記載されています。さらに、内部で使用されるデータ型、削除予定のデータ型もありますがここには記載していません。

Table 3-1. データ型

データ型名エイリアス説明
bigintint88 バイト符号付整数
bigserialserial8自動増分 8 バイト整数
bit 固定長ビット列
bit varying(n)varbit(n)可変長ビット列
booleanbool論理(ブール)値 (真/偽)
box 2 次元平面上の矩形(左下の座標点, 右上の座標点)
bytea バイナリデータ
character(n)char(n)固定長文字列
character varying(n)varchar(n)可変長文字列
cidr IP ネットワークアドレス
circle 2 次元平面上の円(中心点座標, 半径)
date 暦の日付(年月日)
double precisionfloat8倍精度浮動小数点
inet IP ホストアドレス
integerint, int44 バイト符号付整数
interval(p) 日付/時刻の間隔
line 2 次元平面上の無限直線(線上の 1 点, 線上のもう 1 点)
lseg 2 次元平面上の線分(始点の座標, 終点の座標)
macaddr MACアドレス
money 米国通貨
numeric [ (p, s) ]decimal [ (p, s) ]精度の選択可能な整数と小数
oid オブジェクト識別子
path 2 次元平面上の道(点1, 点2, ...)
point 2 次元平面上の点(x, y)
polygon 2 次元平面上の多角形(点1, 点2, ...)
realfloat4単精度浮動小数点
smallintint22 バイト符号付整数
serialserial4自動増分 4 バイト整数
text 可変長文字列(無制限)
time [ (p) ] [ without time zone ] 時間帯無し時刻(時・分・秒)
time [ (p) ] with time zonetimetz時間帯付き時刻(時・分・秒)
timestamp [ (p) ] without time zonetimestamp日付と時刻
timestamp [ (p) ] [ with time zone ]timestamptz時間帯付き日付と時刻

互換性: 次に挙げるデータ型(あるいはその綴り方)は SQL で明記されています。 bit, bit varying, boolean, char, character, character varying, varchar, date, double precision, integer, interval, numeric, decimal, real, smallint, time, timestamp(時間帯付き、無し両方)。

それぞれのデータ型にはそのデータ型の入出力関数を指定する外部表現を保有しています。組み込みデータ型の多くには、はっきりとした外部フォーマットがあります。とはいっても、いくつかのデータ型は開いた、もしくは閉じた道のように PostgreSQL に特有なもの、あるいは日付や時刻データ型のようにフォーマットをいくつか選択できるものがあります。(例えば整数や浮動小数点など)基本の型に対応するほとんどの入出力関数はエラーチェックを行います。入出力関数のあるものは転置することができません。ということは、出力関数による結果は最初の入力と比較した場合精度を失う可能性があります。

(足し算や掛け算などの)いくつかの演算子と関数に関しては、実行速度を上げるるために実行時にはエラーチェックを行いません。例えば、システムによっては知らないうちにいくつかのデータ型に対する数値演算子がアンダーフローやオーバーフローを引き起こすかもしれません。

3.1. 数値データ型

数値データ型には 2、4、8 バイト整数と、4、8 バイト浮動小数点および固定精度整数と小数があります。

Table 3-2. 数値データ型

型名格納サイズ説明範囲
smallint2 バイト固定精度-32768 〜 +32767
integer4 バイト通常使用の固定精度-2147483648 〜 +2147483647
bigint8 バイト超広範囲固定精度-9223372036854775808 〜 9223372036854775807
decimal可変長ユーザー指定精度、正確無制限
numeric可変長ユーザー指定精度、正確無制限
real4 バイト可変精度、不正確6 桁単精度
double precision8 バイト可変精度、不正確15 桁精度
serial4 バイト自動増分整数1 〜 2147483647
bigserial8 バイト自動増分整数1 〜 9223372036854775807

数値データ型に対する定数の構文は Section 1.1.2 で説明されています。数値データ型には対応する算術演算子と関数の一式が揃っています。詳細は Chapter 4 を参照ください。次の節でデータ型について詳しく説明します。

3.1.1. 整数データ型

smallintintegerbigint は数詞全体を保持します。その意味は小数点以下の端数や、変化に富む数値の範囲を保持しません。許容範囲に外れた値を保存しようとするとエラーになります。

integer は数値の範囲、保存のサイズおよびパフォーマンスにおいて最も釣合が取れているので、通常使用されます。 smallint は一般的にディスク容量に制限がついている場合にのみ使用します。bigintinteger が許容する範囲では充分ではない場合にのみ使用すべきでしょう。というのはなんと言っても integer データ型のほうがずっと速いからです。

8 バイト整数をコンパイラがサポートしているかに依存する bigint は、すべてのプラットフォームで正常に機能するとは限りません。サポートしていないマシン上では bigintinteger と同じに振舞います(しかし、領域は 8 ビットまで必要です)。しかしながら、このようなことが現実の問題をおこすそれなりのプラットフォームがあるかどうか判りません。

SQL では整数の型として integer(または int)と smallint のみを規定しています。 bigintint2int4、 および int8 は拡張ですが、ほかのさまざまな RDBMS 製品でも使われています。

Note: インデックスが付けられた smallint あるいは bigint の列がテーブルにある場合、システムがそのインデックスを使用しようとしたとき問題を引き起こすことがあります。例えば句が次のような形式の場合、

... WHERE smallint_column = 42

システムはインデックスを使用しません。なぜなら constant である 42 にシステムが integer を割り当てます。そして、現在 PostgreSQL は 2 つの異なったデータ型が列に混在している時には、インデックスを使うことができません。使う時は constant を単一引用符で括ります。

... WHERE smallint_column = '42'

こうすると、システムは型分析を後廻しにして constant に正しいデータ型を割り振ります。

3.1.2. 任意の精度を持つ数

すべての数を保存し、そしてすべての演算を正確に行なう過程で、 numeric は実質上無制限の大きさと精度を持つ 数を保存することができます。通貨金額やその他正確性が求められる数量を保存するときは特にこの型を推奨します。とはいっても、 numeric は次の節で説明する浮動小数点データ型に比較し動作が非常に遅くなります。

引き続く説明の中で、次の用語を使用します。 numeric(数値)scale(位取り) とは小数点の右側の小数点以下の桁数をいいます。numeric precision(精度)とは数字全体の有効桁数です。すなわち、小数点をはさんでいる両側の桁数の合計です。ですから、数字 23.5141 は精度 6 で 位取り 4 であるといいます。整数値は位取り 0 であると考えられます。

numeric の精度と位取りは共に定義することができます。列のデータ型を numeric と宣言するには次の構文を使います。

NUMERIC(precision, scale)

精度はプラス、位取りは 0 もしくはプラスの数字でなければなりません。

NUMERIC(precision)

次のようにして位取り 0 を選択します。

NUMERIC

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

宣言された列の精度または位取りより、精度または位取りの値が大きい場合、システムが値を丸めようとします。もし宣言された範囲内で丸めることができない時はエラーとなります。

decimalnumeric は等価です。2 つのデータ型は共に SQL 標準に入っています。

3.1.3. 浮動小数点データ型

realdouble precision は不正確な精度が変動する数値データ型です。実際にはこれらのデータ型は通常、使用しているプロセッサ、オペレーティングシステムおよびサポートしているコンパイラの範囲以内で(それぞれ単精度および倍精度の)IEEE 754 バイナリ浮動小数点演算を行なわせるための実装です。

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

  • (金銭金額など)正確な記録と計算が必要なときは numeric をその代わりとして使います。

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

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

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

3.1.4. シリアルデータ型

serial は正確にはデータ型ではなくてテーブルの列に一意の識別子を設定する簡便な表記法です。現在の実装では、

CREATE TABLE tablename (
    colname SERIAL
);

のように指定することは次のように指定することと同じです。

CREATE SEQUENCE tablename_colname_seq;
CREATE TABLE tablename (
    colname integer DEFAULT nextval('tablename_colname_seq') UNIQUE NOT NULL
);

このように整数列を作成し、その列のデフォルト値が連番を発生させる仕組みから割り当てられるようにしました。 UNIQUE と NOT NULL 制約は共に明示的に挿入された値が絶対に重複しないようにするものです。

型の名称で、 serialserial4 は同じです。共に integer 列を作成します。型の名称で bigserialserial8bigint 列を作成することを除いて同じ振舞いをします。もしテーブルの寿命がある間で 231 以上の識別子を使用すると予測される場合 bigserial を使用しなければいけません。

serial をサポートしている暗黙的なシーケンスはシリアルデータ型を持つテーブルが削除されても自動的に削除されません。したがって、下記のコマンドが順に実行された時はほぼ失敗に終ります。

CREATE TABLE tablename (colname SERIAL);
DROP TABLE tablename;
CREATE TABLE tablename (colname SERIAL);

DROP SEQUENCE コマンドで明示的に削除されるまでシーケンスはたぶんデータベースに残ります。(この厄介な問題は将来のリリースで確実に変更されるでしょう。)