Home Explore Blog CI



postgresql

16th chunk of `doc/src/sgml/datatype.sgml`
8398b8b2219e55d33b103ba601d0632afe4e45b4e9cda3400000000100000fa9
 is <literal>LIKE</literal> and
    regular expressions.
   </para>

   <para>
    The characters that can be stored in any of these data types are
    determined by the database character set, which is selected when
    the database is created.  Regardless of the specific character set,
    the character with code zero (sometimes called NUL) cannot be stored.
    For more information refer to <xref linkend="multibyte"/>.
   </para>

   <para>
    The storage requirement for a short string (up to 126 bytes) is 1 byte
    plus the actual string, which includes the space padding in the case of
    <type>character</type>.  Longer strings have 4 bytes of overhead instead
    of 1.  Long strings are compressed by the system automatically, so
    the physical requirement on disk might be less. Very long values are also
    stored in background tables so that they do not interfere with rapid
    access to shorter column values. In any case, the longest
    possible character string that can be stored is about 1 GB. (The
    maximum value that will be allowed for <replaceable>n</replaceable> in the data
    type declaration is less than that. It wouldn't be useful to
    change this because with multibyte character encodings the number of
    characters and bytes can be quite different. If you desire to
    store long strings with no specific upper limit, use
    <type>text</type> or <type>character varying</type> without a length
    specifier, rather than making up an arbitrary length limit.)
   </para>

   <tip>
    <para>
     There is no performance difference among these three types,
     apart from increased storage space when using the blank-padded
     type, and a few extra CPU cycles to check the length when storing into
     a length-constrained column.  While
     <type>character(<replaceable>n</replaceable>)</type> has performance
     advantages in some other database systems, there is no such advantage in
     <productname>PostgreSQL</productname>; in fact
     <type>character(<replaceable>n</replaceable>)</type> is usually the slowest of
     the three because of its additional storage costs.  In most situations
     <type>text</type> or <type>character varying</type> should be used
     instead.
    </para>
   </tip>

   <para>
    Refer to <xref linkend="sql-syntax-strings"/> for information about
    the syntax of string literals, and to <xref linkend="functions"/>
    for information about available operators and functions.
   </para>

   <example>
    <title>Using the Character Types</title>

<programlisting>
CREATE TABLE test1 (a character(4));
INSERT INTO test1 VALUES ('ok');
SELECT a, char_length(a) FROM test1; -- <co id="co.datatype-char"/>
<computeroutput>
  a   | char_length
------+-------------
 ok   |           2
</computeroutput>

CREATE TABLE test2 (b varchar(5));
INSERT INTO test2 VALUES ('ok');
INSERT INTO test2 VALUES ('good      ');
INSERT INTO test2 VALUES ('too long');
<computeroutput>ERROR:  value too long for type character varying(5)</computeroutput>
INSERT INTO test2 VALUES ('too long'::varchar(5)); -- explicit truncation
SELECT b, char_length(b) FROM test2;
<computeroutput>
   b   | char_length
-------+-------------
 ok    |           2
 good  |           5
 too l |           5
</computeroutput>
</programlisting>
    <calloutlist>
     <callout arearefs="co.datatype-char">
      <para>
       The <function>char_length</function> function is discussed in
       <xref linkend="functions-string"/>.
      </para>
     </callout>
    </calloutlist>
   </example>

   <para>
    There are two other fixed-length character types in
    <productname>PostgreSQL</productname>, shown in <xref
    linkend="datatype-character-special-table"/>.
    These are not intended for general-purpose use, only for use
    in the internal system catalogs.
    The <type>name</type> type is used to store identifiers. Its
    length is currently defined as 64 bytes (63 usable characters plus
    terminator) but should be referenced

Title: Character Data Types in PostgreSQL
Summary
The storage requirements and performance of character data types in PostgreSQL are discussed, including the differences between character, character varying, and text types. The character set determines the characters that can be stored, and the storage requirement varies depending on the length of the string. There is no significant performance difference between these types, and text or character varying should be used instead of character in most situations. Examples of using character types are also provided, including creating tables and inserting values, as well as using functions like char_length.