A database is a named collection of SQL objects ("database objects"); every database object (tables, function, etc.) belongs to one and only one database. An application that connects to the database server specifies with its connection request the name of the database it wants to connect to. It is not possible to access more than one database per connection. (But an application is not restricted in the number of connections it opens to the same or other databases.)
Note: SQL calls databases "catalogs", but there is no difference in practice.
In order to create or drop databases, the Postgres postmaster must be up and running (see Section 3.3).
Databases are created with the query language command CREATE DATABASE:
CREATE DATABASE namewhere name can be chosen freely. (Depending on the current implementation, certain characters that are special to the underlying operating system might be prohibited. There will be run-time checks for that.) The current user automatically becomes the owner of the new database. It is the privilege of the owner of a database to remove it later on (which also removes all the objects in it, even if they have a different owner).
The creation of databases is a restricted operation. See Section 7.1.1 how to grant permission.
Bootstrapping. Since you need to be connected to the database server in order to execute the CREATE DATABASE command, the question remains how the first database at any given site can be created. The first database is always created by the initdb command when the data storage area is initialized. (See Section 3.2.) This database is called template1 and cannot be deleted. So to create the first "real" database you can connect to template1.
The name "template1" is no accident: When a new database is created, the template database is essentially cloned. This means that any changes you make in template1 are propagated to all subsequently created databases. This implies that you should not use the template database for real work, but when used judiciously this feature can be convenient.
As an extra convenience, there is also a program that you can execute from the shell to create new databases, createdb.
createdb dbnamecreatedb does no magic. It connects to the template1 database and executes the CREATE DATABASE command, exactly as described above. It uses psql program internally. The reference page on createdb contains the invocation details. In particular, createdb without any arguments will create a database with the current user name, which may or may not be what you want.
It is possible to create a database in a location other than the default. Remember that all database access occurs through the database server backend, so that any location specified must be accessible by the backend.
Alternative database locations are referenced by an environment variable which gives the absolute path to the intended storage location. This environment variable must have been defined before the backend was started. Any valid environment variable name may be used to reference an alternative location, although using variable names with a prefix of PGDATA is recommended to avoid confusion and conflict with other variables.
To create the variable in the environment of the server process you must first shut down the server, define the variable, initialize the data area, and finally restart the server. (See Section 3.6 and Section 3.3.) To set an environment variable, type
To create a data storage area in PGDATA2, ensure that /home/postgres already exists and is writable by the user account that runs the server (see Section 3.1). Then from the command line, type
To create a database at the new location, use the command
CREATE DATABASE name WITH LOCATION = 'location'where location is the environment variable you used, PGDATA2 in this example. The createdb command has the option -D for this purpose.
Database created at alternative locations using this method can be accessed and dropped like any other database.
Note: It can also be possible to specify absolute paths directly to the CREATE DATABASE command without defining environment variables. This is disallowed by default because it is a security risk. To allow it, you must compile Postgres with the C preprocessor macro ALLOW_ABSOLUTE_DBPATHS defined. One way to do this is to run the compilation step like this: gmake CPPFLAGS=-DALLOW_ABSOLUTE_DBPATHS all.
If you see anything in the documentation that is not correct, does not match your experience with the particular feature or requires further clarification, please use this form to report a documentation issue.