any installation-local objects that might have been added to
   <literal>template1</literal>.
  </para>
 </refsect1>

 <refsect1>
  <title>Parameters</title>

    <variablelist>
     <varlistentry id="create-database-name">
      <term><replaceable class="parameter">name</replaceable></term>
      <listitem>
       <para>
        The name of a database to create.
       </para>
      </listitem>
     </varlistentry>
     <varlistentry id="create-database-user-name">
      <term><replaceable class="parameter">user_name</replaceable></term>
      <listitem>
       <para>
        The role name of the user who will own the new database,
        or <literal>DEFAULT</literal> to use the default (namely, the
        user executing the command).  To create a database owned by another
        role, you must be able to <literal>SET ROLE</literal> to that
        role.
       </para>
      </listitem>
     </varlistentry>
     <varlistentry id="create-database-template">
      <term><replaceable class="parameter">template</replaceable></term>
      <listitem>
       <para>
        The name of the template from which to create the new database,
        or <literal>DEFAULT</literal> to use the default template
        (<literal>template1</literal>).
       </para>
      </listitem>
     </varlistentry>
     <varlistentry id="create-database-encoding">
      <term><replaceable class="parameter">encoding</replaceable></term>
      <listitem>
       <para>
        Character set encoding to use in the new database.  Specify
        a string constant (e.g., <literal>'SQL_ASCII'</literal>),
        or an integer encoding number, or <literal>DEFAULT</literal>
        to use the default encoding (namely, the encoding of the
        template database). The character sets supported by the
        <productname>PostgreSQL</productname> server are described in
        <xref linkend="multibyte-charset-supported"/>. See below for
        additional restrictions.
       </para>
      </listitem>
     </varlistentry>
     <varlistentry id="create-database-strategy" xreflabel="CREATE DATABASE STRATEGY">
      <term><replaceable class="parameter">strategy</replaceable></term>
      <listitem>
       <para>
        Strategy to be used in creating the new database.  If
        the <literal>WAL_LOG</literal> strategy is used, the database will be
        copied block by block and each block will be separately written
        to the write-ahead log. This is the most efficient strategy in
        cases where the template database is small, and therefore it is the
        default. The older <literal>FILE_COPY</literal> strategy is also
        available. This strategy writes a small record to the write-ahead log
        for each tablespace used by the target database. Each such record
        represents copying an entire directory to a new location at the
        filesystem level. While this does reduce the write-ahead
        log volume substantially, especially if the template database is large,
        it also forces the system to perform a checkpoint both before and
        after the creation of the new database. In some situations, this may
        have a noticeable negative impact on overall system performance. The
        <literal>FILE_COPY</literal> strategy is affected by the <xref
        linkend="guc_file_copy_method"/> setting.
       </para>
      </listitem>
     </varlistentry>
     <varlistentry id="create-database-locale">
      <term><replaceable class="parameter">locale</replaceable></term>
      <listitem>
       <para>
        Sets the default collation order and character classification in the
        new database.  Collation affects the sort order applied to strings,
        e.g., in queries with <literal>ORDER BY</literal>, as well as the order used in indexes
        on text columns.  Character classification affects the categorization
        of characters, e.g., lower, upper, and digit.  Also sets the
        associated aspects of the operating