1999-07-22 17:09:15 +02:00
|
|
|
<!--
|
2010-09-20 22:08:53 +02:00
|
|
|
doc/src/sgml/ref/create_database.sgml
|
2001-12-08 04:24:40 +01:00
|
|
|
PostgreSQL documentation
|
1999-07-22 17:09:15 +02:00
|
|
|
-->
|
|
|
|
|
2017-10-20 03:16:39 +02:00
|
|
|
<refentry id="sql-createdatabase">
|
2014-02-24 03:25:35 +01:00
|
|
|
<indexterm zone="sql-createdatabase">
|
|
|
|
<primary>CREATE DATABASE</primary>
|
|
|
|
</indexterm>
|
|
|
|
|
1999-07-06 19:16:42 +02:00
|
|
|
<refmeta>
|
2010-04-03 09:23:02 +02:00
|
|
|
<refentrytitle>CREATE DATABASE</refentrytitle>
|
2008-11-14 11:22:48 +01:00
|
|
|
<manvolnum>7</manvolnum>
|
1999-07-06 19:16:42 +02:00
|
|
|
<refmiscinfo>SQL - Language Statements</refmiscinfo>
|
|
|
|
</refmeta>
|
2003-04-22 12:08:08 +02:00
|
|
|
|
1999-07-06 19:16:42 +02:00
|
|
|
<refnamediv>
|
2003-04-22 12:08:08 +02:00
|
|
|
<refname>CREATE DATABASE</refname>
|
|
|
|
<refpurpose>create a new database</refpurpose>
|
1998-12-29 03:24:47 +01:00
|
|
|
</refnamediv>
|
2003-04-22 12:08:08 +02:00
|
|
|
|
1999-07-06 19:16:42 +02:00
|
|
|
<refsynopsisdiv>
|
2003-04-22 12:08:08 +02:00
|
|
|
<synopsis>
|
2017-10-09 04:00:57 +02:00
|
|
|
CREATE DATABASE <replaceable class="parameter">name</replaceable>
|
2009-09-19 12:23:27 +02:00
|
|
|
[ [ WITH ] [ OWNER [=] <replaceable class="parameter">user_name</replaceable> ]
|
2002-02-25 04:37:14 +01:00
|
|
|
[ TEMPLATE [=] <replaceable class="parameter">template</replaceable> ]
|
2004-06-18 08:14:31 +02:00
|
|
|
[ ENCODING [=] <replaceable class="parameter">encoding</replaceable> ]
|
Add new block-by-block strategy for CREATE DATABASE.
Because this strategy logs changes on a block-by-block basis, it
avoids the need to checkpoint before and after the operation.
However, because it logs each changed block individually, it might
generate a lot of extra write-ahead logging if the template database
is large. Therefore, the older strategy remains available via a new
STRATEGY parameter to CREATE DATABASE, and a corresponding --strategy
option to createdb.
Somewhat controversially, this patch assembles the list of relations
to be copied to the new database by reading the pg_class relation of
the template database. Cross-database access like this isn't normally
possible, but it can be made to work here because there can't be any
connections to the database being copied, nor can it contain any
in-doubt transactions. Even so, we have to use lower-level interfaces
than normal, since the table scan and relcache interfaces will not
work for a database to which we're not connected. The advantage of
this approach is that we do not need to rely on the filesystem to
determine what ought to be copied, but instead on PostgreSQL's own
knowledge of the database structure. This avoids, for example,
copying stray files that happen to be located in the source database
directory.
Dilip Kumar, with a fairly large number of cosmetic changes by me.
Reviewed and tested by Ashutosh Sharma, Andres Freund, John Naylor,
Greg Nancarrow, Neha Sharma. Additional feedback from Bruce Momjian,
Heikki Linnakangas, Julien Rouhaud, Adam Brusselback, Kyotaro
Horiguchi, Tomas Vondra, Andrew Dunstan, Álvaro Herrera, and others.
Discussion: http://postgr.es/m/CA+TgmoYtcdxBjLh31DLxUXHxFVMPGzrU5_T=CYCvRyFHywSBUQ@mail.gmail.com
2022-03-29 17:31:43 +02:00
|
|
|
[ STRATEGY [=] <replaceable class="parameter">strategy</replaceable> ] ]
|
2019-07-23 14:40:42 +02:00
|
|
|
[ LOCALE [=] <replaceable class="parameter">locale</replaceable> ]
|
2009-04-06 10:42:53 +02:00
|
|
|
[ LC_COLLATE [=] <replaceable class="parameter">lc_collate</replaceable> ]
|
|
|
|
[ LC_CTYPE [=] <replaceable class="parameter">lc_ctype</replaceable> ]
|
2022-03-17 11:11:21 +01:00
|
|
|
[ ICU_LOCALE [=] <replaceable class="parameter">icu_locale</replaceable> ]
|
|
|
|
[ LOCALE_PROVIDER [=] <replaceable class="parameter">locale_provider</replaceable> ]
|
2022-02-14 08:09:04 +01:00
|
|
|
[ COLLATION_VERSION = <replaceable>collation_version</replaceable> ]
|
2012-06-22 00:06:14 +02:00
|
|
|
[ TABLESPACE [=] <replaceable class="parameter">tablespace_name</replaceable> ]
|
2014-07-02 02:10:38 +02:00
|
|
|
[ ALLOW_CONNECTIONS [=] <replaceable class="parameter">allowconn</replaceable> ]
|
2016-05-31 18:05:22 +02:00
|
|
|
[ CONNECTION LIMIT [=] <replaceable class="parameter">connlimit</replaceable> ]
|
pg_upgrade: Preserve database OIDs.
Commit 9a974cbcba005256a19991203583a94b4f9a21a9 arranged to preserve
relfilenodes and tablespace OIDs. For similar reasons, also arrange
to preserve database OIDs.
One problem is that, up until now, the OIDs assigned to the template0
and postgres databases have not been fixed. This could be a problem
when upgrading, because pg_upgrade might try to migrate a database
from the old cluster to the new cluster while keeping the OID and find
a different database with that OID, resulting in a failure. If it finds
a database with the same name and the same OID that's OK: it will be
dropped and recreated. But the same OID and a different name is a
problem.
To prevent that, fix the OIDs for postgres and template0 to specific
values less than 16384. To avoid running afoul of this rule, these
values should not be changed in future releases. It's not a problem
that these OIDs aren't fixed in existing releases, because the OIDs
that we're assigning here weren't used for either of these databases
in any previous release. Thus, there's no chance that an upgrade of
a cluster from any previous release will collide with the OIDs we're
assigning here. And going forward, the OIDs will always be fixed, so
the only potential collision is with a system database having the
same name and the same OID, which is OK.
This patch lets users assign a specific OID to a database as well,
provided however that it can't be less than 16384. I (rhaas) thought
it might be better not to expose this capability to users, but the
consensus was otherwise, so the syntax is documented. Letting users
assign OIDs below 16384 would not be OK, though, because a
user-created database with a low-numbered OID might collide with a
system-created database in a future release. We therefore prohibit
that.
Shruthi KC, based on an earlier patch from Antonin Houska, reviewed
and with some adjustments by me.
Discussion: http://postgr.es/m/CA+TgmoYgTwYcUmB=e8+hRHOFA0kkS6Kde85+UNdon6q7bt1niQ@mail.gmail.com
Discussion: http://postgr.es/m/CAASxf_Mnwm1Dh2vd5FAhVX6S1nwNSZUB1z12VddYtM++H2+p7w@mail.gmail.com
2022-01-24 20:23:15 +01:00
|
|
|
[ IS_TEMPLATE [=] <replaceable class="parameter">istemplate</replaceable> ]
|
|
|
|
[ OID [=] <replaceable class="parameter">oid</replaceable> ] ]
|
2003-04-22 12:08:08 +02:00
|
|
|
</synopsis>
|
|
|
|
</refsynopsisdiv>
|
|
|
|
|
|
|
|
<refsect1>
|
|
|
|
<title>Description</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
<command>CREATE DATABASE</command> creates a new
|
|
|
|
<productname>PostgreSQL</productname> database.
|
|
|
|
</para>
|
|
|
|
|
2003-09-12 02:12:47 +02:00
|
|
|
<para>
|
|
|
|
To create a database, you must be a superuser or have the special
|
2017-10-09 03:44:17 +02:00
|
|
|
<literal>CREATEDB</literal> privilege.
|
2017-11-23 15:39:47 +01:00
|
|
|
See <xref linkend="sql-createrole"/>.
|
2003-09-12 02:12:47 +02:00
|
|
|
</para>
|
|
|
|
|
2003-04-22 12:08:08 +02:00
|
|
|
<para>
|
|
|
|
By default, the new database will be created by cloning the standard
|
2017-10-09 03:44:17 +02:00
|
|
|
system database <literal>template1</literal>. A different template can be
|
2003-04-22 12:08:08 +02:00
|
|
|
specified by writing <literal>TEMPLATE
|
|
|
|
<replaceable class="parameter">name</replaceable></literal>. In particular,
|
2019-11-14 21:33:26 +01:00
|
|
|
by writing <literal>TEMPLATE template0</literal>, you can create a pristine
|
|
|
|
database (one where no user-defined objects exist and where the system
|
|
|
|
objects have not been altered)
|
|
|
|
containing only the standard objects predefined by your
|
2003-04-22 12:08:08 +02:00
|
|
|
version of <productname>PostgreSQL</productname>. This is useful
|
|
|
|
if you wish to avoid copying
|
Update reference documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
2007-02-01 00:26:05 +01:00
|
|
|
any installation-local objects that might have been added to
|
2017-10-09 03:44:17 +02:00
|
|
|
<literal>template1</literal>.
|
2003-04-22 12:08:08 +02:00
|
|
|
</para>
|
|
|
|
</refsect1>
|
|
|
|
|
|
|
|
<refsect1>
|
2003-09-12 02:12:47 +02:00
|
|
|
<title>Parameters</title>
|
1999-07-06 19:16:42 +02:00
|
|
|
|
|
|
|
<variablelist>
|
|
|
|
<varlistentry>
|
|
|
|
<term><replaceable class="parameter">name</replaceable></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
2004-06-18 08:14:31 +02:00
|
|
|
The name of a database to create.
|
1999-07-06 19:16:42 +02:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
2002-02-24 21:20:21 +01:00
|
|
|
<varlistentry>
|
2012-03-11 21:56:26 +01:00
|
|
|
<term><replaceable class="parameter">user_name</replaceable></term>
|
2002-02-24 21:20:21 +01:00
|
|
|
<listitem>
|
|
|
|
<para>
|
2012-10-04 19:41:01 +02:00
|
|
|
The role name of the user who will own the new database,
|
2004-06-18 08:14:31 +02:00
|
|
|
or <literal>DEFAULT</literal> to use the default (namely, the
|
2012-10-04 19:41:01 +02:00
|
|
|
user executing the command). To create a database owned by another
|
|
|
|
role, you must be a direct or indirect member of that role,
|
|
|
|
or be a superuser.
|
2002-02-24 21:20:21 +01:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
1999-07-06 19:16:42 +02:00
|
|
|
<varlistentry>
|
2004-06-18 08:14:31 +02:00
|
|
|
<term><replaceable class="parameter">template</replaceable></term>
|
1999-07-06 19:16:42 +02:00
|
|
|
<listitem>
|
|
|
|
<para>
|
2004-06-18 08:14:31 +02:00
|
|
|
The name of the template from which to create the new database,
|
|
|
|
or <literal>DEFAULT</literal> to use the default template
|
|
|
|
(<literal>template1</literal>).
|
2000-11-14 19:37:49 +01:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
2004-06-18 08:14:31 +02:00
|
|
|
<term><replaceable class="parameter">encoding</replaceable></term>
|
2000-11-14 19:37:49 +01:00
|
|
|
<listitem>
|
|
|
|
<para>
|
2004-06-18 08:14:31 +02:00
|
|
|
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>
|
2006-05-04 18:07:29 +02:00
|
|
|
to use the default encoding (namely, the encoding of the
|
|
|
|
template database). The character sets supported by the
|
2004-06-18 08:14:31 +02:00
|
|
|
<productname>PostgreSQL</productname> server are described in
|
2017-11-23 15:39:47 +01:00
|
|
|
<xref linkend="multibyte-charset-supported"/>. See below for
|
2007-09-29 00:25:49 +02:00
|
|
|
additional restrictions.
|
2000-11-14 19:37:49 +01:00
|
|
|
</para>
|
|
|
|
</listitem>
|
Add new block-by-block strategy for CREATE DATABASE.
Because this strategy logs changes on a block-by-block basis, it
avoids the need to checkpoint before and after the operation.
However, because it logs each changed block individually, it might
generate a lot of extra write-ahead logging if the template database
is large. Therefore, the older strategy remains available via a new
STRATEGY parameter to CREATE DATABASE, and a corresponding --strategy
option to createdb.
Somewhat controversially, this patch assembles the list of relations
to be copied to the new database by reading the pg_class relation of
the template database. Cross-database access like this isn't normally
possible, but it can be made to work here because there can't be any
connections to the database being copied, nor can it contain any
in-doubt transactions. Even so, we have to use lower-level interfaces
than normal, since the table scan and relcache interfaces will not
work for a database to which we're not connected. The advantage of
this approach is that we do not need to rely on the filesystem to
determine what ought to be copied, but instead on PostgreSQL's own
knowledge of the database structure. This avoids, for example,
copying stray files that happen to be located in the source database
directory.
Dilip Kumar, with a fairly large number of cosmetic changes by me.
Reviewed and tested by Ashutosh Sharma, Andres Freund, John Naylor,
Greg Nancarrow, Neha Sharma. Additional feedback from Bruce Momjian,
Heikki Linnakangas, Julien Rouhaud, Adam Brusselback, Kyotaro
Horiguchi, Tomas Vondra, Andrew Dunstan, Álvaro Herrera, and others.
Discussion: http://postgr.es/m/CA+TgmoYtcdxBjLh31DLxUXHxFVMPGzrU5_T=CYCvRyFHywSBUQ@mail.gmail.com
2022-03-29 17:31:43 +02:00
|
|
|
</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-ahed
|
|
|
|
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.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
2000-11-14 19:37:49 +01:00
|
|
|
</varlistentry>
|
2019-07-23 14:40:42 +02:00
|
|
|
<varlistentry>
|
|
|
|
<term><replaceable class="parameter">locale</replaceable></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
This is a shortcut for setting <symbol>LC_COLLATE</symbol>
|
|
|
|
and <symbol>LC_CTYPE</symbol> at once. If you specify this,
|
|
|
|
you cannot specify either of those parameters.
|
|
|
|
</para>
|
|
|
|
<tip>
|
|
|
|
<para>
|
|
|
|
The other locale settings <xref linkend="guc-lc-messages"/>, <xref
|
|
|
|
linkend="guc-lc-monetary"/>, <xref linkend="guc-lc-numeric"/>, and
|
|
|
|
<xref linkend="guc-lc-time"/> are not fixed per database and are not
|
|
|
|
set by this command. If you want to make them the default for a
|
|
|
|
specific database, you can use <literal>ALTER DATABASE
|
|
|
|
... SET</literal>.
|
|
|
|
</para>
|
|
|
|
</tip>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
2008-09-23 11:20:39 +02:00
|
|
|
<varlistentry>
|
2009-05-06 18:15:21 +02:00
|
|
|
<term><replaceable class="parameter">lc_collate</replaceable></term>
|
2008-09-23 11:20:39 +02:00
|
|
|
<listitem>
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
Collation order (<literal>LC_COLLATE</literal>) to use in the new database.
|
2020-09-01 00:33:37 +02:00
|
|
|
This affects the sort order applied to strings, e.g., in queries with
|
2008-09-23 11:20:39 +02:00
|
|
|
ORDER BY, as well as the order used in indexes on text columns.
|
|
|
|
The default is to use the collation order of the template database.
|
|
|
|
See below for additional restrictions.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
2009-05-06 18:15:21 +02:00
|
|
|
<term><replaceable class="parameter">lc_ctype</replaceable></term>
|
2008-09-23 11:20:39 +02:00
|
|
|
<listitem>
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
Character classification (<literal>LC_CTYPE</literal>) to use in the new
|
2020-09-01 00:33:37 +02:00
|
|
|
database. This affects the categorization of characters, e.g., lower,
|
2008-09-23 11:20:39 +02:00
|
|
|
upper and digit. The default is to use the character classification of
|
|
|
|
the template database. See below for additional restrictions.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
2022-02-14 08:09:04 +01:00
|
|
|
|
2022-03-17 11:11:21 +01:00
|
|
|
<varlistentry>
|
|
|
|
<term><replaceable class="parameter">icu_locale</replaceable></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
Specifies the ICU locale ID if the ICU locale provider is used.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
<term><replaceable>locale_provider</replaceable></term>
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
Specifies the provider to use for the default collation in this
|
|
|
|
database. Possible values are:
|
|
|
|
<literal>icu</literal>,<indexterm><primary>ICU</primary></indexterm>
|
|
|
|
<literal>libc</literal>. <literal>libc</literal> is the default. The
|
|
|
|
available choices depend on the operating system and build options.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
2022-02-14 08:09:04 +01:00
|
|
|
<varlistentry>
|
|
|
|
<term><replaceable>collation_version</replaceable></term>
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
Specifies the collation version string to store with the database.
|
|
|
|
Normally, this should be omitted, which will cause the version to be
|
|
|
|
computed from the actual version of the database collation as provided
|
|
|
|
by the operating system. This option is intended to be used by
|
|
|
|
<command>pg_upgrade</command> for copying the version from an existing
|
|
|
|
installation.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
See also <xref linkend="sql-alterdatabase"/> for how to handle
|
|
|
|
database collation version mismatches.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
2000-11-14 19:37:49 +01:00
|
|
|
<varlistentry>
|
2012-06-22 00:06:14 +02:00
|
|
|
<term><replaceable class="parameter">tablespace_name</replaceable></term>
|
2000-11-14 19:37:49 +01:00
|
|
|
<listitem>
|
|
|
|
<para>
|
2004-10-29 05:17:22 +02:00
|
|
|
The name of the tablespace that will be associated with the
|
|
|
|
new database, or <literal>DEFAULT</literal> to use the
|
|
|
|
template database's tablespace. This
|
|
|
|
tablespace will be the default tablespace used for objects
|
|
|
|
created in this database. See
|
2017-11-23 15:39:47 +01:00
|
|
|
<xref linkend="sql-createtablespace"/>
|
2004-06-18 08:14:31 +02:00
|
|
|
for more information.
|
1999-07-06 19:16:42 +02:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
2005-07-31 19:19:22 +02:00
|
|
|
|
2014-07-02 02:10:38 +02:00
|
|
|
<varlistentry>
|
|
|
|
<term><replaceable class="parameter">allowconn</replaceable></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
If false then no one can connect to this database. The default is
|
|
|
|
true, allowing connections (except as restricted by other mechanisms,
|
2017-10-09 03:44:17 +02:00
|
|
|
such as <literal>GRANT</literal>/<literal>REVOKE CONNECT</literal>).
|
2014-07-02 02:10:38 +02:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
2015-09-11 03:22:21 +02:00
|
|
|
|
2014-07-02 02:10:38 +02:00
|
|
|
<varlistentry>
|
2005-07-31 19:19:22 +02:00
|
|
|
<term><replaceable class="parameter">connlimit</replaceable></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
How many concurrent connections can be made
|
|
|
|
to this database. -1 (the default) means no limit.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
2015-09-18 02:56:58 +02:00
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
<term><replaceable class="parameter">istemplate</replaceable></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
If true, then this database can be cloned by any user with <literal>CREATEDB</literal>
|
|
|
|
privileges; if false (the default), then only superusers or the owner
|
|
|
|
of the database can clone it.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
pg_upgrade: Preserve database OIDs.
Commit 9a974cbcba005256a19991203583a94b4f9a21a9 arranged to preserve
relfilenodes and tablespace OIDs. For similar reasons, also arrange
to preserve database OIDs.
One problem is that, up until now, the OIDs assigned to the template0
and postgres databases have not been fixed. This could be a problem
when upgrading, because pg_upgrade might try to migrate a database
from the old cluster to the new cluster while keeping the OID and find
a different database with that OID, resulting in a failure. If it finds
a database with the same name and the same OID that's OK: it will be
dropped and recreated. But the same OID and a different name is a
problem.
To prevent that, fix the OIDs for postgres and template0 to specific
values less than 16384. To avoid running afoul of this rule, these
values should not be changed in future releases. It's not a problem
that these OIDs aren't fixed in existing releases, because the OIDs
that we're assigning here weren't used for either of these databases
in any previous release. Thus, there's no chance that an upgrade of
a cluster from any previous release will collide with the OIDs we're
assigning here. And going forward, the OIDs will always be fixed, so
the only potential collision is with a system database having the
same name and the same OID, which is OK.
This patch lets users assign a specific OID to a database as well,
provided however that it can't be less than 16384. I (rhaas) thought
it might be better not to expose this capability to users, but the
consensus was otherwise, so the syntax is documented. Letting users
assign OIDs below 16384 would not be OK, though, because a
user-created database with a low-numbered OID might collide with a
system-created database in a future release. We therefore prohibit
that.
Shruthi KC, based on an earlier patch from Antonin Houska, reviewed
and with some adjustments by me.
Discussion: http://postgr.es/m/CA+TgmoYgTwYcUmB=e8+hRHOFA0kkS6Kde85+UNdon6q7bt1niQ@mail.gmail.com
Discussion: http://postgr.es/m/CAASxf_Mnwm1Dh2vd5FAhVX6S1nwNSZUB1z12VddYtM++H2+p7w@mail.gmail.com
2022-01-24 20:23:15 +01:00
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
<term><replaceable class="parameter">oid</replaceable></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
The object identifier to be used for the new database. If this
|
|
|
|
parameter is not specified, the database will choose a suitable
|
|
|
|
OID automatically. This parameter is primarily intended for internal
|
|
|
|
use by <application>pg_upgrade</application>, and only
|
|
|
|
<application>pg_upgrade</application> can specify a value less
|
|
|
|
than 16384.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
1999-07-06 19:16:42 +02:00
|
|
|
</variablelist>
|
2003-04-22 12:08:08 +02:00
|
|
|
|
|
|
|
<para>
|
|
|
|
Optional parameters can be written in any order, not only the order
|
|
|
|
illustrated above.
|
|
|
|
</para>
|
|
|
|
</refsect1>
|
|
|
|
|
|
|
|
<refsect1>
|
2003-09-12 02:12:47 +02:00
|
|
|
<title>Notes</title>
|
1999-12-12 06:15:10 +01:00
|
|
|
|
2003-09-12 02:12:47 +02:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
<command>CREATE DATABASE</command> cannot be executed inside a transaction
|
2003-09-12 02:12:47 +02:00
|
|
|
block.
|
|
|
|
</para>
|
2000-11-14 19:37:49 +01:00
|
|
|
|
2003-09-12 02:12:47 +02:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
Errors along the line of <quote>could not initialize database directory</quote>
|
2003-09-12 02:12:47 +02:00
|
|
|
are most likely related to insufficient permissions on the data
|
2004-06-18 08:14:31 +02:00
|
|
|
directory, a full disk, or other file system problems.
|
2003-09-12 02:12:47 +02:00
|
|
|
</para>
|
2000-11-14 19:37:49 +01:00
|
|
|
|
1998-05-13 07:34:00 +02:00
|
|
|
<para>
|
Improve <xref> vs. <command> formatting in the documentation
SQL commands are generally marked up as <command>, except when a link
to a reference page is used using <xref>. But the latter doesn't
create monospace markup, so this looks strange especially when a
paragraph contains a mix of links and non-links.
We considered putting <command> in the <refentrytitle> on the target
side, but that creates some formatting side effects elsewhere.
Generally, it seems safer to solve this on the link source side.
We can't put the <xref> inside the <command>; the DTD doesn't allow
this. DocBook 5 would allow the <command> to have the linkend
attribute itself, but we are not there yet.
So to solve this for now, convert the <xref>s to <link> plus
<command>. This gives the correct look and also gives some more
flexibility what we can put into the link text (e.g., subcommands or
other clauses). In the future, these could then be converted to
DocBook 5 style.
I haven't converted absolutely all xrefs to SQL command reference
pages, only those where we care about the appearance of the link text
or where it was otherwise appropriate to make the appearance match a
bit better. Also in some cases, the links where repetitive, so in
those cases the links where just removed and replaced by a plain
<command>. In cases where we just want the link and don't
specifically care about the generated link text (typically phrased
"for further information see <xref ...>") the xref is kept.
Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
|
|
|
Use <link linkend="sql-dropdatabase"><command>DROP DATABASE</command></link> to remove a database.
|
1999-12-12 06:15:10 +01:00
|
|
|
</para>
|
1999-07-22 17:09:15 +02:00
|
|
|
|
|
|
|
<para>
|
2017-11-23 15:39:47 +01:00
|
|
|
The program <xref linkend="app-createdb"/> is a
|
2003-04-22 12:08:08 +02:00
|
|
|
wrapper program around this command, provided for convenience.
|
1999-07-22 17:09:15 +02:00
|
|
|
</para>
|
|
|
|
|
2014-04-19 21:26:49 +02:00
|
|
|
<para>
|
Improve <xref> vs. <command> formatting in the documentation
SQL commands are generally marked up as <command>, except when a link
to a reference page is used using <xref>. But the latter doesn't
create monospace markup, so this looks strange especially when a
paragraph contains a mix of links and non-links.
We considered putting <command> in the <refentrytitle> on the target
side, but that creates some formatting side effects elsewhere.
Generally, it seems safer to solve this on the link source side.
We can't put the <xref> inside the <command>; the DTD doesn't allow
this. DocBook 5 would allow the <command> to have the linkend
attribute itself, but we are not there yet.
So to solve this for now, convert the <xref>s to <link> plus
<command>. This gives the correct look and also gives some more
flexibility what we can put into the link text (e.g., subcommands or
other clauses). In the future, these could then be converted to
DocBook 5 style.
I haven't converted absolutely all xrefs to SQL command reference
pages, only those where we care about the appearance of the link text
or where it was otherwise appropriate to make the appearance match a
bit better. Also in some cases, the links where repetitive, so in
those cases the links where just removed and replaced by a plain
<command>. In cases where we just want the link and don't
specifically care about the generated link text (typically phrased
"for further information see <xref ...>") the xref is kept.
Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
|
|
|
Database-level configuration parameters (set via <link
|
|
|
|
linkend="sql-alterdatabase"><command>ALTER DATABASE</command></link>) and database-level permissions (set via
|
|
|
|
<link linkend="sql-grant"><command>GRANT</command></link>) are not copied from the template database.
|
2014-04-19 21:26:49 +02:00
|
|
|
</para>
|
|
|
|
|
2000-11-14 19:37:49 +01:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
Although it is possible to copy a database other than <literal>template1</literal>
|
2001-11-18 01:38:00 +01:00
|
|
|
by specifying its name as the template, this is not (yet) intended as
|
2003-04-22 12:08:08 +02:00
|
|
|
a general-purpose <quote><command>COPY DATABASE</command></quote> facility.
|
2006-05-04 18:07:29 +02:00
|
|
|
The principal limitation is that no other sessions can be connected to
|
|
|
|
the template database while it is being copied. <command>CREATE
|
2017-10-09 03:44:17 +02:00
|
|
|
DATABASE</command> will fail if any other connection exists when it starts;
|
2006-05-04 18:07:29 +02:00
|
|
|
otherwise, new connections to the template database are locked out
|
2017-10-09 03:44:17 +02:00
|
|
|
until <command>CREATE DATABASE</command> completes.
|
2017-11-23 15:39:47 +01:00
|
|
|
See <xref linkend="manage-ag-templatedbs"/> for more information.
|
2001-08-26 18:56:03 +02:00
|
|
|
</para>
|
2005-07-31 19:19:22 +02:00
|
|
|
|
2007-09-29 00:25:49 +02:00
|
|
|
<para>
|
2008-09-23 11:20:39 +02:00
|
|
|
The character set encoding specified for the new database must be
|
2017-10-09 03:44:17 +02:00
|
|
|
compatible with the chosen locale settings (<literal>LC_COLLATE</literal> and
|
|
|
|
<literal>LC_CTYPE</literal>). If the locale is <literal>C</literal> (or equivalently
|
|
|
|
<literal>POSIX</literal>), then all encodings are allowed, but for other
|
2008-09-23 11:20:39 +02:00
|
|
|
locale settings there is only one encoding that will work properly.
|
2009-05-06 18:15:21 +02:00
|
|
|
(On Windows, however, UTF-8 encoding can be used with any locale.)
|
2017-10-09 03:44:17 +02:00
|
|
|
<command>CREATE DATABASE</command> will allow superusers to specify
|
|
|
|
<literal>SQL_ASCII</literal> encoding regardless of the locale settings,
|
2007-09-29 00:25:49 +02:00
|
|
|
but this choice is deprecated and may result in misbehavior of
|
|
|
|
character-string functions if data that is not encoding-compatible
|
|
|
|
with the locale is stored in the database.
|
|
|
|
</para>
|
|
|
|
|
2008-09-23 11:20:39 +02:00
|
|
|
<para>
|
2009-05-06 18:15:21 +02:00
|
|
|
The encoding and locale settings must match those of the template database,
|
2017-10-09 03:44:17 +02:00
|
|
|
except when <literal>template0</literal> is used as template. This is because
|
2009-05-06 18:15:21 +02:00
|
|
|
other databases might contain data that does not match the specified
|
|
|
|
encoding, or might contain indexes whose sort ordering is affected by
|
2017-10-09 03:44:17 +02:00
|
|
|
<literal>LC_COLLATE</literal> and <literal>LC_CTYPE</literal>. Copying such data would
|
2009-05-06 18:15:21 +02:00
|
|
|
result in a database that is corrupt according to the new settings.
|
|
|
|
<literal>template0</literal>, however, is known to not contain any data or
|
|
|
|
indexes that would be affected.
|
2008-09-23 11:20:39 +02:00
|
|
|
</para>
|
|
|
|
|
2022-03-17 11:11:21 +01:00
|
|
|
<para>
|
|
|
|
There is currently no option to use a database locale with nondeterministic
|
|
|
|
comparisons (see <link linkend="sql-createcollation"><command>CREATE
|
|
|
|
COLLATION</command></link> for an explanation). If this is needed, then
|
|
|
|
per-column collations would need to be used.
|
|
|
|
</para>
|
|
|
|
|
2005-07-31 19:19:22 +02:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
The <literal>CONNECTION LIMIT</literal> option is only enforced approximately;
|
2005-07-31 19:19:22 +02:00
|
|
|
if two new sessions start at about the same time when just one
|
2017-10-09 03:44:17 +02:00
|
|
|
connection <quote>slot</quote> remains for the database, it is possible that
|
2017-02-01 23:52:35 +01:00
|
|
|
both will fail. Also, the limit is not enforced against superusers or
|
|
|
|
background worker processes.
|
2005-07-31 19:19:22 +02:00
|
|
|
</para>
|
1998-12-29 03:24:47 +01:00
|
|
|
</refsect1>
|
1999-07-06 19:16:42 +02:00
|
|
|
|
2003-04-22 12:08:08 +02:00
|
|
|
<refsect1>
|
|
|
|
<title>Examples</title>
|
|
|
|
|
1999-07-06 19:16:42 +02:00
|
|
|
<para>
|
1998-05-13 07:34:00 +02:00
|
|
|
To create a new database:
|
1999-07-06 19:16:42 +02:00
|
|
|
|
2003-04-22 12:08:08 +02:00
|
|
|
<programlisting>
|
|
|
|
CREATE DATABASE lusiadas;
|
2004-07-12 03:22:53 +02:00
|
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
To create a database <literal>sales</literal> owned by user <literal>salesapp</literal>
|
|
|
|
with a default tablespace of <literal>salesspace</literal>:
|
2004-07-12 03:22:53 +02:00
|
|
|
|
|
|
|
<programlisting>
|
|
|
|
CREATE DATABASE sales OWNER salesapp TABLESPACE salesspace;
|
|
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
To create a database <literal>music</literal> with a different locale:
|
2017-02-02 20:57:46 +01:00
|
|
|
<programlisting>
|
|
|
|
CREATE DATABASE music
|
2019-07-23 14:40:42 +02:00
|
|
|
LOCALE 'sv_SE.utf8'
|
2017-02-02 20:57:46 +01:00
|
|
|
TEMPLATE template0;
|
|
|
|
</programlisting>
|
2017-10-09 03:44:17 +02:00
|
|
|
In this example, the <literal>TEMPLATE template0</literal> clause is required if
|
|
|
|
the specified locale is different from the one in <literal>template1</literal>.
|
2017-02-02 20:57:46 +01:00
|
|
|
(If it is not, then specifying the locale explicitly is redundant.)
|
|
|
|
</para>
|
2004-07-12 03:22:53 +02:00
|
|
|
|
2017-02-02 20:57:46 +01:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
To create a database <literal>music2</literal> with a different locale and a
|
2017-02-02 20:57:46 +01:00
|
|
|
different character set encoding:
|
2004-07-12 03:22:53 +02:00
|
|
|
<programlisting>
|
2017-02-02 20:57:46 +01:00
|
|
|
CREATE DATABASE music2
|
2019-07-23 14:40:42 +02:00
|
|
|
LOCALE 'sv_SE.iso885915'
|
2017-02-02 20:57:46 +01:00
|
|
|
ENCODING LATIN9
|
|
|
|
TEMPLATE template0;
|
2003-04-22 12:08:08 +02:00
|
|
|
</programlisting>
|
2017-02-02 20:57:46 +01:00
|
|
|
The specified locale and encoding settings must match, or an error will be
|
|
|
|
reported.
|
|
|
|
</para>
|
2009-05-06 18:15:21 +02:00
|
|
|
|
2017-02-02 20:57:46 +01:00
|
|
|
<para>
|
|
|
|
Note that locale names are specific to the operating system, so that the
|
|
|
|
above commands might not work in the same way everywhere.
|
1999-07-06 19:16:42 +02:00
|
|
|
</para>
|
|
|
|
</refsect1>
|
|
|
|
|
2003-04-22 12:08:08 +02:00
|
|
|
<refsect1>
|
|
|
|
<title>Compatibility</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
There is no <command>CREATE DATABASE</command> statement in the SQL
|
|
|
|
standard. Databases are equivalent to catalogs, whose creation is
|
|
|
|
implementation-defined.
|
|
|
|
</para>
|
1998-05-13 07:34:00 +02:00
|
|
|
</refsect1>
|
2006-05-04 18:07:29 +02:00
|
|
|
|
|
|
|
<refsect1>
|
|
|
|
<title>See Also</title>
|
|
|
|
|
|
|
|
<simplelist type="inline">
|
2017-11-23 15:39:47 +01:00
|
|
|
<member><xref linkend="sql-alterdatabase"/></member>
|
|
|
|
<member><xref linkend="sql-dropdatabase"/></member>
|
2006-05-04 18:07:29 +02:00
|
|
|
</simplelist>
|
|
|
|
</refsect1>
|
|
|
|
|
1999-07-06 19:16:42 +02:00
|
|
|
</refentry>
|