<literal>pg_database</literal><indexterm><primary>pg_database</primary></indexterm> for each
   database: the columns <literal>datistemplate</literal> and
   <literal>datallowconn</literal>.  <literal>datistemplate</literal>
   can be set to indicate that a database is intended as a template for
   <command>CREATE DATABASE</command>.  If this flag is set, the database can be
   cloned by any user with <literal>CREATEDB</literal> privileges; if it is not set,
   only superusers and the owner of the database can clone it.
   If <literal>datallowconn</literal> is false, then no new connections
   to that database will be allowed (but existing sessions are not terminated
   simply by setting the flag false).  The <literal>template0</literal>
   database is normally marked <literal>datallowconn = false</literal> to prevent its modification.
   Both <literal>template0</literal> and <literal>template1</literal>
   should always be marked with <literal>datistemplate = true</literal>.
  </para>

  <note>
   <para>
    <literal>template1</literal> and <literal>template0</literal> do not have any special
    status beyond the fact that the name <literal>template1</literal> is the default
    source database name for <command>CREATE DATABASE</command>.
    For example, one could drop <literal>template1</literal> and recreate it from
    <literal>template0</literal> without any ill effects.  This course of action
    might be advisable if one has carelessly added a bunch of junk in
    <literal>template1</literal>. (To delete <literal>template1</literal>,
    it must have <literal>pg_database.datistemplate = false</literal>.)
   </para>

   <para>
    The <literal>postgres</literal> database is also created when a database
    cluster is initialized.  This database is meant as a default database for
    users and applications to connect to. It is simply a copy of
    <literal>template1</literal> and can be dropped and recreated if necessary.
   </para>
  </note>
 </sect1>

 <sect1 id="manage-ag-config">
  <title>Database Configuration</title>

  <para>
   Recall from <xref linkend="runtime-config"/> that the
   <productname>PostgreSQL</productname> server provides a large number of
   run-time configuration variables.  You can set database-specific
   default values for many of these settings.
  </para>

  <para>
   For example, if for some reason you want to disable the
   <acronym>GEQO</acronym> optimizer for a given database, you'd
   ordinarily have to either disable it for all databases or make sure
   that every connecting client is careful to issue <literal>SET geqo
   TO off</literal>.  To make this setting the default within a particular
   database, you can execute the command:
<programlisting>
ALTER DATABASE mydb SET geqo TO off;
</programlisting>
   This will save the setting (but not set it immediately).  In
   subsequent connections to this database it will appear as though
   <literal>SET geqo TO off;</literal> had been executed just before the
   session started.
   Note that users can still alter this setting during their sessions; it
   will only be the default.  To undo any such setting, use
   <literal>ALTER DATABASE <replaceable>dbname</replaceable> RESET
   <replaceable>varname</replaceable></literal>.
  </para>
 </sect1>

 <sect1 id="manage-ag-dropdb">
  <title>Destroying a Database</title>

  <para>
   Databases are destroyed with the command
   <xref linkend="sql-dropdatabase"/>:<indexterm><primary>DROP DATABASE</primary></indexterm>
<synopsis>
DROP DATABASE <replaceable>name</replaceable>;
</synopsis>
   Only the owner of the database, or
   a superuser, can drop a database. Dropping a database removes all objects
   that were
   contained within the database. The destruction of a database cannot
   be undone.
  </para>

  <para>
   You cannot execute the <command>DROP DATABASE</command> command
   while connected to the victim database. You can, however, be
   connected to any other database, including the <literal>template1</literal>