<type>sql_identifier</type>
      </para>
      <para>
       Applies to a feature not available in <productname>PostgreSQL</productname>
      </para></entry>
     </row>

     <row>
      <entry role="catalog_table_entry"><para role="column_definition">
       <structfield>maximum_cardinality</structfield> <type>cardinal_number</type>
      </para>
      <para>
       Always null, because arrays always have unlimited maximum cardinality in <productname>PostgreSQL</productname>
      </para></entry>
     </row>

     <row>
      <entry role="catalog_table_entry"><para role="column_definition">
       <structfield>dtd_identifier</structfield> <type>sql_identifier</type>
      </para>
      <para>
       An identifier of the data type descriptor of the attribute, unique
       among the data type descriptors pertaining to the composite type.  This
       is mainly useful for joining with other instances of such
       identifiers.  (The specific format of the identifier is not
       defined and not guaranteed to remain the same in future
       versions.)
      </para></entry>
     </row>

     <row>
      <entry role="catalog_table_entry"><para role="column_definition">
       <structfield>is_derived_reference_attribute</structfield> <type>yes_or_no</type>
      </para>
      <para>
       Applies to a feature not available in <productname>PostgreSQL</productname>
      </para></entry>
     </row>
    </tbody>
   </tgroup>
  </table>

  <para>
   See also under <xref linkend="infoschema-columns"/>, a similarly
   structured view, for further information on some of the columns.
  </para>
 </sect1>

 <sect1 id="infoschema-character-sets">
  <title><literal>character_sets</literal></title>

  <para>
   The view <literal>character_sets</literal> identifies the character
   sets available in the current database.  Since PostgreSQL does not
   support multiple character sets within one database, this view only
   shows one, which is the database encoding.
  </para>

  <para>
   Take note of how the following terms are used in the SQL standard:
   <variablelist>
    <varlistentry>
     <term>character repertoire</term>
     <listitem>
      <para>
       An abstract collection of characters, for
       example <literal>UNICODE</literal>, <literal>UCS</literal>, or
       <literal>LATIN1</literal>.  Not exposed as an SQL object, but
       visible in this view.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term>character encoding form</term>
     <listitem>
      <para>
       An encoding of some character repertoire.  Most older character
       repertoires only use one encoding form, and so there are no
       separate names for them (e.g., <literal>LATIN2</literal> is an
       encoding form applicable to the <literal>LATIN2</literal>
       repertoire).  But for example Unicode has the encoding forms
       <literal>UTF8</literal>, <literal>UTF16</literal>, etc. (not
       all supported by PostgreSQL).  Encoding forms are not exposed
       as an SQL object, but are visible in this view.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term>character set</term>
     <listitem>
      <para>
       A named SQL object that identifies a character repertoire, a
       character encoding, and a default collation.  A predefined
       character set would typically have the same name as an encoding
       form, but users could define other names.  For example, the
       character set <literal>UTF8</literal> would typically identify
       the character repertoire <literal>UCS</literal>, encoding
       form <literal>UTF8</literal>, and some default collation.
      </para>
     </listitem>
    </varlistentry>
   </variablelist>

   You can think of an <quote>encoding</quote> in PostgreSQL either as
   a character set or a character encoding form.  They will have the
   same name, and there can only be one in one database.
  </para>

  <table>
   <title><structname>character_sets</structname>