<!-- doc/src/sgml/information_schema.sgml -->

<chapter id="information-schema">
 <title>The Information Schema</title>

 <indexterm zone="information-schema">
  <primary>information schema</primary>
 </indexterm>

 <para>
  The information schema consists of a set of views that contain
  information about the objects defined in the current database.  The
  information schema is defined in the SQL standard and can therefore
  be expected to be portable and remain stable &mdash; unlike the system
  catalogs, which are specific to
  <productname>PostgreSQL</productname> and are modeled after
  implementation concerns.  The information schema views do not,
  however, contain information about
  <productname>PostgreSQL</productname>-specific features; to inquire
  about those you need to query the system catalogs or other
  <productname>PostgreSQL</productname>-specific views.
 </para>

 <note>
  <para>
   When querying the database for constraint information, it is possible
   for a standard-compliant query that expects to return one row to
   return several.  This is because the SQL standard requires constraint
   names to be unique within a schema, but
   <productname>PostgreSQL</productname> does not enforce this
   restriction.  <productname>PostgreSQL</productname>
   automatically-generated constraint names avoid duplicates in the
   same schema, but users can specify such duplicate names.
  </para>

  <para>
   This problem can appear when querying information schema views such
   as <literal>check_constraint_routine_usage</literal>,
   <literal>check_constraints</literal>, <literal>domain_constraints</literal>, and
   <literal>referential_constraints</literal>.  Some other views have similar
   issues but contain the table name to help distinguish duplicate
   rows, e.g., <literal>constraint_column_usage</literal>,
   <literal>constraint_table_usage</literal>, <literal>table_constraints</literal>.
  </para>
 </note>


 <sect1 id="infoschema-schema">
  <title>The Schema</title>

  <para>
   The information schema itself is a schema named
   <literal>information_schema</literal>.  This schema automatically
   exists in all databases.  The owner of this schema is the initial
   database user in the cluster, and that user naturally has all the
   privileges on this schema, including the ability to drop it (but
   the space savings achieved by that are minuscule).
  </para>

  <para>
   By default, the information schema is not in the schema search
   path, so you need to access all objects in it through qualified
   names.  Since the names of some of the objects in the information
   schema are generic names that might occur in user applications, you
   should be careful if you want to put the information schema in the
   path.
  </para>
 </sect1>

 <sect1 id="infoschema-datatypes">
  <title>Data Types</title>

  <para>
   The columns of the information schema views use special data types
   that are defined in the information schema.  These are defined as
   simple domains over ordinary built-in types.  You should not use
   these types for work outside the information schema, but your
   applications must be prepared for them if they select from the
   information schema.
  </para>

  <para>
   These types are:

   <variablelist>
    <varlistentry>
     <term><type>cardinal_number</type></term>
     <listitem>
      <para>
       A nonnegative integer.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><type>character_data</type></term>
     <listitem>
      <para>
       A character string (without specific maximum length).
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><type>sql_identifier</type></term>
     <listitem>
      <para>
       A character string.  This type is used for SQL identifiers, the
       type <type>character_data</type> is used for any other kind of
       text data.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>