A PostgreSQL database cluster (installation) contains one or more named databases. Users and groups of users are shared across the entire cluster, but no other data is shared across databases. Any given client connection to the server can access only the data in a single database, the one specified in the connection request.
Note: Users of a cluster do not necessarily have the privilege to access every database in the cluster. Sharing of user names means that there cannot be different users named, say, joe in two databases in the same cluster; but the system can be configured to allow joe access to only some of the databases.
A database contains one or more named schemas, which in turn contain tables. Schemas also contain other kinds of named objects, including datatypes, functions, and operators. The same object name can be used in different schemas without conflict; for example, both schema1 and myschema may contain tables named mytable. Unlike databases, schemas are not rigidly separated: a user may access objects in any of the schemas in the database he is connected to, if he has privileges to do so.
To name a table precisely, write a qualified name consisting of the schema name and table name separated by a dot:
schema.table
Actually, the even more general syntax
database.schema.table
can be used too, but at present this is just for pro-forma compliance with the SQL standard; if you write a database name it must be the same as the database you are connected to.
Qualified names are tedious to write, and it's often best not to wire a particular schema name into applications anyway. Therefore tables are often referred to by unqualified names, which consist of just the table name. The system determines which table is meant by following a search path, which is a list of schemas to look in. The first matching table in the search path is taken to be the one wanted. If there is no match in the search path, an error is reported, even if matching table names exist in other schemas in the database.
The first schema named in the search path is called the current schema. Aside from being the first schema searched, it is also the schema in which new tables will be created if the CREATE TABLE command does not specify a schema name.
The search path works in the same way for datatype names, function names, and operator names as it does for table names. Datatype and function names can be qualified in exactly the same way as table names. If you need to write a qualified operator name in an expression, there is a special provision: you must write
OPERATOR(schema.operator)
This is needed to avoid syntactic ambiguity. An example is
SELECT 3 OPERATOR(pg_catalog.+) 4;
In practice one usually relies on the search path for operators, so as not to have to write anything so ugly as that.
The standard search path in PostgreSQL contains first the schema having the same name as the session user (if it exists), and second the schema named public (if it exists, which it does by default). This arrangement allows a flexible combination of private and shared tables. If no per-user schemas are created then all user tables will exist in the shared public schema, providing behavior that is backwards-compatible with pre-7.3 PostgreSQL releases.
Note: There is no concept of a public schema in the SQL standard. To achieve closest conformance to the standard, the DBA should create per-user schemas for every user, and not use (perhaps even remove) the public schema.
In addition to public and user-created schemas, each database contains a pg_catalog schema, which contains the system tables and all the built-in datatypes, functions, and operators. pg_catalog is always effectively part of the search path. If it is not named explicitly in the path then it is implicitly searched before searching the path's schemas. This ensures that built-in names will always be findable. However, you may explicitly place pg_catalog at the end of your search path if you prefer to have user-defined names override built-in names.
The search path is determined by the GUC variable SEARCH_PATH and may be changed at any time. See SET SEARCH_PATH.
There are several restrictions on the names that can be chosen for user-defined database objects. These restrictions vary depending on the kind of object. (Note that these restrictions are separate from whether the name is a key word or not; quoting a name will not allow you to escape these restrictions.)
Schema names beginning with pg_ are reserved for system purposes and may not be created by users.
In PostgreSQL versions before 7.3, table names beginning with pg_ were reserved. This is no longer true: you may create such a table name if you wish, in any non-system schema. However, it's best to continue to avoid such names, to ensure that you won't suffer a conflict if some future version defines a system catalog named the same as your table. (With the default search path, an unqualified reference to your table name would be resolved as the system catalog instead.) System catalogs will continue to follow the convention of having names beginning with pg_, so that they will not conflict with unqualified user-table names so long as users avoid the pg_ prefix.
Every table has several system columns that are implicitly defined by the system. Therefore, these names cannot be used as names of user-defined columns:
The object identifier (object ID) of a row. This is a serial number that is automatically added by PostgreSQL to all table rows (unless the table was created WITHOUT OIDS, in which case this column is not present). See Section 5.10 for more info.
The OID of the table containing this row. This attribute is particularly handy for queries that select from inheritance hierarchies, since without it, it's difficult to tell which individual table a row came from. The tableoid can be joined against the oid column of pg_class to obtain the table name.
The identity (transaction ID) of the inserting transaction for this tuple. (Note: A tuple is an individual state of a row; each update of a row creates a new tuple for the same logical row.)
The command identifier (starting at zero) within the inserting transaction.
The identity (transaction ID) of the deleting transaction, or zero for an undeleted tuple. It is possible for this field to be nonzero in a visible tuple: that usually indicates that the deleting transaction hasn't committed yet, or that an attempted deletion was rolled back.
The command identifier within the deleting transaction, or zero.
The physical location of the tuple within its table. Note that although the ctid can be used to locate the tuple very quickly, a row's ctid will change each time it is updated or moved by VACUUM FULL. Therefore ctid is useless as a long-term row identifier. The OID, or even better a user-defined serial number, should be used to identify logical rows.