他のバージョンの文書 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

8.3. 文字型

表8.4 文字型

型名説明
character varying(n), varchar(n)上限付き可変長
character(n), char(n)空白で埋められた固定長
text制限なし可変長

表 8.4PostgreSQLで使用可能な汎用文字型を示したものです。

SQLは2つの主要な文字データ型を定義しています。 character varying(n)character(n)です。 ここでnは正の整数です。 これらのデータ型は2つともn文字長(バイト数ではなく)までの文字列を保存できます。 上限を越えた文字列をこれらの型の列に保存しようとするとエラーになります。 ただし、上限を超えた部分にある文字がすべて空白の場合はエラーにはならず、文字列の最大長にまで切り詰められます。 (この一風変わった例外は標準SQLで要求されています。) もし宣言された上限よりも文字列が短い時はcharacterの値は空白で埋められ、character varyingの値は単にその短い文字列で保存されます。

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

char(n)およびvarchar(n)という表記法はそれぞれcharacter(n)character varying(n)の別名です。 長さ指定がないcharactercharacter(1)と同じです。 character varyingが長さ指定なしで使われた時は、いかなる長さの文字列でも受け付けます。 後者はPostgreSQLの拡張です。

さらにPostgreSQLは、いかなる長さの文字列でも格納できるtextをサポートします。 text型は標準SQLにはありませんが、多くの他のSQLデータベース管理システムも同様にサポートしています。

character型の値は、指定長nになるまで物理的に空白で埋められ、そのまま格納、表示されます。 しかし、最後の空白は、重要ではないものとして扱われ、2つのcharacter型の値を比べる際には無視されます。 空白が重要な照合順序では、この挙動は予期しない結果を返す可能性があります。例えば、SELECT 'a '::CHAR(2) collate "C" < E'a\n'::CHAR(2)Cロケールでスペースが改行よりも大きいにも関わらず真を返します。 character値を他の文字列型に変換する際は、文字列の終わりの空白は除去されます。 character varying型とtext型の値の中や、パターンマッチを行なう際、すなわちLIKEや正規表現では、最後の空白は意味的に重要なものですので、注意してください。

これらのデータ型のいずれかに格納できる文字はデータベースを作成するときに選択されるデータベースキャラクタセットによって決定されます。 特定のキャラクタセットに関わらず、コード0(時にはNULと呼ばれます)を格納することはできません。 より詳細な情報は24.3を参照ください。

短い文字列(126バイトまで)の保存には、実際の文字列に1バイト加えたサイズが必要です。 characterでは空白埋め込み分もこれに含まれます。 より長い文字列では1バイトではなく4バイトのオーバーヘッドになります。 長い文字列はシステムにより自動的に圧縮されますので、ディスク上の物理的必要容量サイズはより小さくなるかもしれません。 また、非常に長い値はより短い列の値への高速アクセスに干渉しないように、バックグラウンドテーブルに格納されます。 いずれの場合にあっても保存できる最長の文字列は約1ギガバイトです。 (データ型宣言に使われるnに許される最大値はこれより小さいものです。 マルチバイト文字符号化方式においては文字数とバイト数はまったく異なっているため、この値の変更は便利ではありません。 特定の上限を設けずに長い文字列を保存したい場合は、適当な上限を設けるよりも、textもしくは長さの指定がないcharacter varyingを使用してください。)

ヒント

空白で埋められる型を使用した場合の保存領域の増加、および、長さ制限付きの列に格納する際に長さを検査するためにいくつか余計なCPUサイクルが加わる点を別にして、これら3つの型の間で性能に関する差異はありません。 他の一部のデータベースシステムではcharacter(n)には性能的な優位性がありますが、PostgreSQLではこうした利点はありません。 実際には、格納の際に追加のコストがあるため、character(n)は3つの中でもっとも低速です。 多くの場合、代わりにtextcharacter varyingを使うのがお薦めです。

文字列リテラルの構文については4.1.2.1、利用可能な演算子と関数については第9章を参照してください。

例8.1 文字データ型の使用

CREATE TABLE test1 (a character(4));
INSERT INTO test1 VALUES ('ok');
SELECT a, char_length(a) FROM test1; -- (1)

  a   | char_length
------+-------------
 ok   |           2


CREATE TABLE test2 (b varchar(5));
INSERT INTO test2 VALUES ('ok');
INSERT INTO test2 VALUES ('good      ');
INSERT INTO test2 VALUES ('too long');
ERROR:  value too long for type character varying(5)

INSERT INTO test2 VALUES ('too long'::varchar(5)); -- 明示的な切り捨て
SELECT b, char_length(b) FROM test2;

   b   | char_length
-------+-------------
 ok    |           2
 good  |           5
 too l |           5

(1)

char_length関数は9.4で説明されています。


PostgreSQLには、表 8.5に示すように、この他2つの固定長文字型があります。 name型は内部のシステムカタログ内の識別子の格納のためにのみ存在するもので、一般ユーザによって使用されることを意図していません。 現在長さは64バイト(63バイトの利用可能文字と終止文字)と定義されていますが、CソースコードにあるNAMEDATALEN定数を使って参照される必要があります。 この長さはコンパイル時に設定されます(そのため特別な用途に合わせ調整できます)。 デフォルトの最大長は今後のリリースで変更される可能性があります。 "char"(二重引用符に注意)は、char(1)とは異なり、1バイトの領域しか使用しません。 過度に単純化した列挙型としてシステムカタログで内部的に使用されます。

表8.5 特別な文字データ型

型名格納サイズ説明
"char"1バイト単一バイト内部データ型
name64バイトオブジェクト名用の内部データ型