<!--
-$PostgreSQL: pgsql/doc/src/sgml/manage-ag.sgml,v 2.31 2004/06/21 04:06:03 tgl Exp $
+$PostgreSQL: pgsql/doc/src/sgml/manage-ag.sgml,v 2.32 2004/08/07 19:02:43 tgl Exp $
-->
<chapter id="managing-databases">
are accessible from each database within the cluster.) More
accurately, a database is a collection of schemas and the schemas
contain the tables, functions, etc. So the full hierarchy is:
- server, database, schema, table (or something else instead of a
- table).
+ server, database, schema, table (or some other kind of object,
+ such as a function).
</para>
<para>
<note>
<para>
- <acronym>SQL</> calls databases <quote>catalogs</>, but there is no
- difference in practice.
+ The <acronym>SQL</> standard calls databases <quote>catalogs</>, but there
+ is no difference in practice.
</para>
</note>
</sect1>
<title>Creating a Database</title>
<para>
- In order to create a database
s, the <productname>PostgreSQL</>
+ In order to create a database, the <productname>PostgreSQL</>
server must be up and running (see <xref
linkend="postmaster-start">).
</para>
<para>
- Databases are created with the SQL command <command>CREATE
- DATABASE</command>:<indexterm><primary>CREATE DATABASE</></>
+ Databases are created with the SQL command
+ <xref linkend="sql-createdatabase"
+ endterm="sql-createdatabase-title">:<indexterm><primary>CREATE
+ DATABASE</></>
<synopsis>
CREATE DATABASE <replaceable>name</>;
</synopsis>
</para>
<para>
- The name <literal>template1</literal> is no accident: When a new
+ The name <literal>template1</literal> is no accident: when a new
database is created, the template database is essentially cloned.
This means that any changes you make in <literal>template1</> are
propagated to all subsequently created databases. This implies that
<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 you can
- execute the command
+ 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>
<title>Destroying a Database</title>
<para>
- Databases are destroyed with the command <command>DROP
- DATABASE</command>:<indexterm><primary>DROP DATABASE</></>
+ Databases are destroyed with the command
+ <xref linkend="sql-dropdatabase"
+ endterm="sql-dropdatabase-title">:<indexterm><primary>DROP DATABASE</></>
<synopsis>
DROP DATABASE <replaceable>name</>;
</synopsis>
- Only the owner of the database (i.e., the user that created it) or
+ Only the owner of the database (i.e., the user that created it), 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
<title>Tablespaces</title>
<para>
- Tablespaces in <productname>PostgreSQL</> allow database superusers to
+ Tablespaces in <productname>PostgreSQL</> allow database administrators to
define locations in the file system where the files representing
database objects can be stored. Once created, a tablespace can be referred
to by name when creating database objects.
</para>
<para>
- Databases, schemas, tables, indexes and sequences can all be placed in
+ To define a tablespace, use the <xref linkend="sql-createtablespace"
+ endterm="sql-createtablespace-title"> command, for
+ example:<indexterm><primary>CREATE TABLESPACE</></>
+<programlisting>
+CREATE TABLESPACE fastspace LOCATION '/mnt/sda1/postgresql/data';
+</programlisting>
+ The location must be an existing, empty directory that is owned by
+ the <productname>PostgreSQL</> system user. All objects subsequently
+ created within the tablespace will be stored in files underneath this
+ directory.
+ </para>
+
+ <note>
+ <para>
+ There is usually not much point in making more than one
+ tablespace per logical filesystem, since you can't control the location
+ of individual files within a logical filesystem. However,
+ <productname>PostgreSQL</> does not enforce any such limitation, and
+ indeed it's not directly aware of the filesystem boundaries on your
+ system. It just stores files in the directories you tell it to use.
+ </para>
+ </note>
+
+ <para>
+ Creation of the tablespace itself must be done as a database superuser,
+ but after that you can allow ordinary database users to make use of it.
+ To do that, grant them the <literal>CREATE</> privilege on it.
+ </para>
+
+ <para>
+ Databases, schemas, tables, and indexes can all be assigned to
particular tablespaces. To do so, a user with the <literal>CREATE</>
privilege on a given tablespace must pass the tablespace name as a
parameter to the relevant command. For example, the following creates
A schema does not in itself occupy any storage (other than a system
catalog entry), so assigning a tablespace to a schema does not in itself
do anything. What this actually does is to set a default tablespace
- for tables, indexes, and sequences later created within the schema. If
+ for tables later created within the schema. If
no tablespace is mentioned when creating a schema, it inherits its
default tablespace from the current database.
</para>
</para>
<para>
- Another way to state the above rules is that when a schema, table, index
- or sequence is created without specifying a tablespace, the object
+ Another way to state the above rules is that when a schema, table, or index
+ is created without specifying a tablespace, the object
inherits its logical parent's tablespace. A schema will be created in the
- current database's tablespace; a table or sequence will be created in the
+ current database's tablespace; a table will be created in the
tablespace of the schema it is being created in; an index will be created
in the tablespace of the table underlying the index.
</para>
projects / postgresql / commitdiff