essentially cloned.
   This means that any changes you make in <literal>template1</literal> are
   propagated to all subsequently created databases. Because of this,
   avoid creating objects in <literal>template1</literal> unless you want them
   propagated to every newly created database.
   <literal>template0</literal> is meant as a pristine copy of the original
   contents of <literal>template1</literal>.  It can be cloned instead
   of <literal>template1</literal> when it is important to make a database
   without any such site-local additions.  More details
   appear in <xref linkend="manage-ag-templatedbs"/>.
  </para>

  <para>
   As a convenience, there is a program you can
   execute from the shell to create new databases,
   <command>createdb</command>.<indexterm><primary>createdb</primary></indexterm>

<synopsis>
createdb <replaceable class="parameter">dbname</replaceable>
</synopsis>

   <command>createdb</command> does no magic. It connects to the <literal>postgres</literal>
   database and issues the <command>CREATE DATABASE</command> command,
   exactly as described above.
   The <xref linkend="app-createdb"/> reference page contains the invocation
   details. Note that <command>createdb</command> without any arguments will create
   a database with the current user name.
  </para>

  <note>
   <para>
    <xref linkend="client-authentication"/> contains information about
    how to restrict who can connect to a given database.
   </para>
  </note>

  <para>
   Sometimes you want to create a database for someone else, and have them
   become the owner of the new database, so they can
   configure and manage it themselves.  To achieve that, use one of the
   following commands:
<programlisting>
CREATE DATABASE <replaceable>dbname</replaceable> OWNER <replaceable>rolename</replaceable>;
</programlisting>
   from the SQL environment, or:
<programlisting>
createdb -O <replaceable>rolename</replaceable> <replaceable>dbname</replaceable>
</programlisting>
   from the shell.
   Only the superuser is allowed to create a database for
   someone else (that is, for a role you are not a member of).
  </para>
 </sect1>

 <sect1 id="manage-ag-templatedbs">
  <title>Template Databases</title>

  <para>
   <command>CREATE DATABASE</command> actually works by copying an existing
   database.  By default, it copies the standard system database named
   <literal>template1</literal>.<indexterm><primary>template1</primary></indexterm> Thus that
   database is the <quote>template</quote> from which new databases are
   made.  If you add objects to <literal>template1</literal>, these objects
   will be copied into subsequently created user databases.  This
   behavior allows site-local modifications to the standard set of
   objects in databases.  For example, if you install the procedural
   language <application>PL/Perl</application> in <literal>template1</literal>, it will
   automatically be available in user databases without any extra
   action being taken when those databases are created.
  </para>

  <para>
   However, <command>CREATE DATABASE</command> does not copy database-level
   <command>GRANT</command> permissions attached to the source database.
   The new database has default database-level permissions.
  </para>

  <para>
   There is a second standard system database named
   <literal>template0</literal>.<indexterm><primary>template0</primary></indexterm> This
   database contains the same data as the initial contents of
   <literal>template1</literal>, that is, only the standard objects
   predefined by your version of
   <productname>PostgreSQL</productname>.  <literal>template0</literal>
   should never be changed after the database cluster has been
   initialized.  By instructing
   <command>CREATE DATABASE</command> to copy <literal>template0</literal> instead
   of <literal>template1</literal>, you can create a <quote>pristine</quote> user
   database (one where no user-defined objects exist and where the system