<replaceable>n</replaceable> characters without
    raising an error. (This too is required by the
    <acronym>SQL</acronym> standard.)
    If the string to be stored is shorter than the declared
    length, values of type <type>character</type> will be space-padded;
    values of type <type>character varying</type> will simply store the
    shorter
    string.
   </para>

   <para>
    In addition, <productname>PostgreSQL</productname> provides the
    <type>text</type> type, which stores strings of any length.
    Although the <type>text</type> type is not in the
    <acronym>SQL</acronym> standard, several other SQL database
    management systems have it as well.
    <type>text</type> is <productname>PostgreSQL</productname>'s native
    string data type, in that most built-in functions operating on strings
    are declared to take or return <type>text</type> not <type>character
    varying</type>.  For many purposes, <type>character varying</type>
    acts as though it were a <link linkend="domains">domain</link>
    over <type>text</type>.
   </para>

   <para>
    The type name <type>varchar</type> is an alias for <type>character
    varying</type>, while <type>bpchar</type> (with length specifier) and
    <type>char</type> are aliases for <type>character</type>.  The
    <type>varchar</type> and <type>char</type> aliases are defined in the
    <acronym>SQL</acronym> standard;  <type>bpchar</type> is a
    <productname>PostgreSQL</productname> extension.
   </para>

   <para>
    If specified, the length <replaceable>n</replaceable> must be greater
    than zero and cannot exceed 10,485,760.  If <type>character
    varying</type> (or <type>varchar</type>) is used without
    length specifier, the type accepts strings of any length. If
    <type>bpchar</type> lacks a length specifier, it also accepts strings
    of any length, but trailing spaces are semantically insignificant.
    If <type>character</type> (or <type>char</type>) lacks a specifier,
    it is equivalent to <type>character(1)</type>.
   </para>

   <para>
    Values of type <type>character</type> are physically padded
    with spaces to the specified width <replaceable>n</replaceable>, and are
    stored and displayed that way.  However, trailing spaces are treated as
    semantically insignificant and disregarded when comparing two values
    of type <type>character</type>.  In collations where whitespace
    is significant, this behavior can produce unexpected results;
    for example <command>SELECT 'a '::CHAR(2) collate "C" &lt;
    E'a\n'::CHAR(2)</command> returns true, even though <literal>C</literal>
    locale would consider a space to be greater than a newline.
    Trailing spaces are removed when converting a <type>character</type> value
    to one of the other string types.  Note that trailing spaces
    <emphasis>are</emphasis> semantically significant in
    <type>character varying</type> and <type>text</type> values, and
    when using pattern matching, that 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