<command>ALTER DATABASE</command> is used to change the session
default of a run-time configuration variable for a
<productname>PostgreSQL</productname> database. Whenever a new
- session is subsequently started, <literal>SET
+ session is subsequently started in that database, <literal>SET
<replaceable>variable</replaceable> TO
<replaceable>value</replaceable></literal> is effectively executed
- before the start of the session.
+ before the start of the session. The database-specific default
+ overrides whatever setting is present in <filename>postgresql.conf</>
+ or has been received from the postmaster.
</para>
<para>
- Only a database owner can change the session defaults for a
- database. Superusers can change the session defaults of any
+ Only a superuser or the database owner can change the session defaults for a
database.
</para>
<para>
Using <xref linkend="sql-alteruser" endterm="sql-alteruser-title">,
it is also possible to tie a session default to a specific user
- rather than a database.
+ rather than a database. User-specific settings override database-specific
+ ones if there is a conflict.
</para>
</refsect1>
ALTER TABLE [ ONLY ] <replaceable class="PARAMETER">table</replaceable> [ * ]
ADD [ COLUMN ] <replaceable class="PARAMETER">column</replaceable> <replaceable class="PARAMETER">type</replaceable> [ <replaceable class="PARAMETER">column_constraint</replaceable> [ ... ] ]
ALTER TABLE [ ONLY ] <replaceable class="PARAMETER">table</replaceable> [ * ]
- ALTER [ COLUMN ] <replaceable class="PARAMETER">column</replaceable> { SET DEFAULT <replaceable
- class="PARAMETER">value</replaceable> | DROP DEFAULT }
+ ALTER [ COLUMN ] <replaceable class="PARAMETER">column</replaceable> { SET DEFAULT <replaceable class="PARAMETER">value</replaceable> | DROP DEFAULT }
ALTER TABLE [ ONLY ] <replaceable class="PARAMETER">table</replaceable> [ * ]
ALTER [ COLUMN ] <replaceable class="PARAMETER">column</replaceable> { SET | DROP } NOT NULL
ALTER TABLE [ ONLY ] <replaceable class="PARAMETER">table</replaceable> [ * ]
ALTER [ COLUMN ] <replaceable class="PARAMETER">column</replaceable> SET STATISTICS <replaceable class="PARAMETER">integer</replaceable>
ALTER TABLE [ ONLY ] <replaceable class="PARAMETER">table</replaceable> [ * ]
- ALTER [ COLUMN ] <replaceable class="PARAMETER">column</replaceable> SET STORAGE {PLAIN | EXTERNAL | EXTENDED | MAIN}
+ ALTER [ COLUMN ] <replaceable class="PARAMETER">column</replaceable> SET STORAGE { PLAIN | EXTERNAL | EXTENDED | MAIN }
ALTER TABLE [ ONLY ] <replaceable class="PARAMETER">table</replaceable> [ * ]
RENAME [ COLUMN ] <replaceable class="PARAMETER">column</replaceable> TO <replaceable
- class="PARAMETER">newcolumn</replaceable>
+ class="PARAMETER">new_column</replaceable>
ALTER TABLE <replaceable class="PARAMETER">table</replaceable>
RENAME TO <replaceable class="PARAMETER">new_table</replaceable>
ALTER TABLE <replaceable class="PARAMETER">table</replaceable>
ADD <replaceable class="PARAMETER">table_constraint_definition</replaceable>
ALTER TABLE [ ONLY ] <replaceable class="PARAMETER">table</replaceable>
- DROP CONSTRAINT <replaceable class="PARAMETER">constraint</replaceable> { RESTRICT | CASCADE }
+ DROP CONSTRAINT <replaceable class="PARAMETER">constraint_name</replaceable> { RESTRICT | CASCADE }
ALTER TABLE <replaceable class="PARAMETER">table</replaceable>
OWNER TO <replaceable class="PARAMETER">new_owner</replaceable>
</synopsis>
<term><replaceable class="PARAMETER"> table </replaceable></term>
<listitem>
<para>
- The name of an existing table to alter.
+ The name (possibly schema-qualified) of an existing table to alter.
</para>
</listitem>
</varlistentry>
</varlistentry>
<varlistentry>
- <term><replaceable class="PARAMETER"> newcolumn </replaceable></term>
+ <term><replaceable class="PARAMETER"> new_column </replaceable></term>
<listitem>
<para>
New name for an existing column.
<term><replaceable class="PARAMETER"> table_constraint_definition </replaceable></term>
<listitem>
<para>
- New table constraint for the table
+ New table constraint for the table.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><replaceable class="PARAMETER"> constraint_name </replaceable></term>
+ <listitem>
+ <para>
+ Name of an existing constraint to drop.
</para>
</listitem>
</varlistentry>
</title>
<para>
<command>ALTER TABLE</command> changes the definition of an existing table.
- The <literal>ADD COLUMN</literal> form adds a new column to the table
- using the same syntax as <xref linkend="SQL-CREATETABLE" endterm="SQL-CREATETABLE-TITLE">.
- The <literal>ALTER COLUMN SET/DROP DEFAULT</literal> forms
- allow you to set or remove the default for the column. Note that defaults
- only apply to subsequent <command>INSERT</command> commands; they do not
- cause rows already in the table to change.
- The <literal>ALTER COLUMN SET/DROP NOT NULL</literal> forms allow you to
- change whether a column is marked to allow NULL values or to reject NULL
- values.
- The <literal>ALTER COLUMN SET STATISTICS</literal> form allows you to
- set the statistics-gathering target for subsequent
- <xref linkend="sql-analyze" endterm="sql-analyze-title"> operations.
- The <literal>ALTER COLUMN SET STORAGE</literal> form allows the
- column storage mode to be set. This controls whether this column is
- held inline or in a supplementary table, and whether the data
- should be compressed or not. <literal>PLAIN</literal> must be used
- for fixed-length values such as <literal>INTEGER</literal> and is
- inline, uncompressed. <literal>MAIN</literal> is for inline,
- compressible data. <literal>EXTERNAL</literal> is for external,
- uncompressed data and <literal>EXTENDED</literal> is for external,
- compressed data. The use of <literal>EXTERNAL</literal> will make
- substring operations on a column faster, at the penalty of
- increased storage space.
- The <literal>RENAME</literal> clause causes the name of a table,
- column, index, sequence or view to change without changing any of the
- data. The data will remain of the same type and size after the
- command is executed.
- The ADD <replaceable class="PARAMETER">table_constraint_definition</replaceable> clause
- adds a new constraint to the table using the same syntax as <xref
- linkend="SQL-CREATETABLE" endterm="SQL-CREATETABLE-TITLE">.
- The DROP CONSTRAINT <replaceable class="PARAMETER">constraint</replaceable> clause
- drops all constraints on the table (and its children) that match <replaceable class="PARAMETER">constraint</replaceable>.
- The OWNER clause changes the owner of the table, index, sequence or view to the
- user <replaceable class="PARAMETER">new user</replaceable>.
+ There are several sub-forms:
</para>
+ <variablelist>
+
+ <varlistentry>
+ <term>ADD COLUMN</term>
+ <listitem>
+ <para>
+ This form adds a new column to the table using the same syntax as
+ <xref linkend="SQL-CREATETABLE" endterm="SQL-CREATETABLE-TITLE">.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>SET/DROP DEFAULT</term>
+ <listitem>
+ <para>
+ These forms set or remove the default value for a column. Note
+ that defaults only apply to subsequent <command>INSERT</command>
+ commands; they do not cause rows already in the table to change.
+ Defaults may also be created for views, in which case they are
+ inserted into <command>INSERT</> statements on the view before
+ the view's ON INSERT rule is applied.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>SET/DROP NOT NULL</term>
+ <listitem>
+ <para>
+ These forms change whether a column is marked to allow NULL
+ values or to reject NULL values. You may only <literal>SET NOT NULL</>
+ when the table contains no NULLs in the column.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>SET STATISTICS</term>
+ <listitem>
+ <para>
+ This form
+ sets the per-column statistics-gathering target for subsequent
+ <xref linkend="sql-analyze" endterm="sql-analyze-title"> operations.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>SET STORAGE</term>
+ <listitem>
+ <para>
+ This form sets the storage mode for a column. This controls whether this
+ column is held inline or in a supplementary table, and whether the data
+ should be compressed or not. <literal>PLAIN</literal> must be used
+ for fixed-length values such as <literal>INTEGER</literal> and is
+ inline, uncompressed. <literal>MAIN</literal> is for inline,
+ compressible data. <literal>EXTERNAL</literal> is for external,
+ uncompressed data and <literal>EXTENDED</literal> is for external,
+ compressed data. <literal>EXTENDED</literal> is the default for all
+ datatypes that support it. The use of <literal>EXTERNAL</literal> will
+ make substring operations on a TEXT column faster, at the penalty of
+ increased storage space.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>RENAME</term>
+ <listitem>
+ <para>
+ The <literal>RENAME</literal> forms change the name of a table
+ (or an index, sequence, or view) or the name of an individual column in
+ a table. There is no effect on the stored data.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>ADD <replaceable class="PARAMETER">table_constraint_definition</replaceable></term>
+ <listitem>
+ <para>
+ This form adds a new constraint to a table using the same syntax as
+ <xref linkend="SQL-CREATETABLE" endterm="SQL-CREATETABLE-TITLE">.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>DROP CONSTRAINT</term>
+ <listitem>
+ <para>
+ This form drops constraints on a table (and its children).
+ Currently, constraints on tables are not required to have unique
+ names, so there may be more than one constraint matching the specified
+ name. All such constraints will be dropped.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>OWNER</term>
+ <listitem>
+ <para>
+ This form changes the owner of the table, index, sequence or view to the
+ specified user.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ </variablelist>
+
<para>
- You must own the table in order to change its schema.
+ You must own the table to use <command>ALTER TABLE</>; except for
+ <command>ALTER TABLE OWNER</>, which may only be executed by a superuser.
</para>
<refsect2 id="R2-SQL-ALTERTABLE-3">
<para>
In the current implementation of <literal>ADD COLUMN</literal>,
default and NOT NULL clauses for the new column are not supported.
+ The new column always comes into being with all values NULL.
You can use the <literal>SET DEFAULT</literal> form
- of <command>ALTER TABLE</command> to set the default later.
+ of <command>ALTER TABLE</command> to set the default afterwards.
(You may also want to update the already existing rows to the
- new default value, using <xref linkend="sql-update" endterm="sql-update-title">.)
+ new default value, using
+ <xref linkend="sql-update" endterm="sql-update-title">.)
+ If you want to mark the column non-null, use the <literal>SET NOT NULL</>
+ form after you've entered non-null values for the column in all rows.
</para>
<para>
In DROP CONSTRAINT, the RESTRICT keyword is required, although
dependencies are not yet checked. The CASCADE option is unsupported.
- Currently DROP CONSTRAINT drops only CHECK constraints.
+ Currently DROP CONSTRAINT only handles CHECK constraints.
To remove a PRIMARY or UNIQUE constraint, drop the
relevant index using the <xref linkend="SQL-DROPINDEX" endterm="sql-dropindex-title"> command.
To remove FOREIGN KEY constraints you need to recreate
</para>
<para>
- You must own the table in order to change it.
Changing any part of the schema of a system
catalog is not permitted.
- The <citetitle>PostgreSQL User's Guide</citetitle> has further
- information on inheritance.
</para>
<para>
Refer to <command>CREATE TABLE</command> for a further description
of valid arguments.
+ The <citetitle>PostgreSQL User's Guide</citetitle> has further
+ information on inheritance.
</para>
</refsect2>
</refsect1>
<term><replaceable class="PARAMETER">table</replaceable></term>
<listitem>
<para>
- The name of a specific table to analyze. Defaults to all tables.
+ The name (possibly schema-qualified) of a specific table to
+ analyze. Defaults to all tables in the current database.
</para>
</listitem>
</varlistentry>
<term><replaceable class="PARAMETER">table</replaceable></term>
<listitem>
<para>
- The name of a table.
+ The name (possibly schema-qualified) of a table.
</para>
</listitem>
</varlistentry>
<variablelist>
<varlistentry>
- <term><replaceable class="PARAMETER">object_name, table_name,
- column_name, agg_name, func_name, op, rule_name, trigger_name</replaceable></term>
+ <term><replaceable class="PARAMETER">object_name,
+ table_name.column_name, agg_name, func_name, op, rule_name, trigger_name</replaceable></term>
<listitem>
<para>
- The name of the object to be be commented.
+ The name of the object to be be commented. Names of tables,
+ indexes, sequences, views, types, domains, functions, aggregates,
+ and operators may be schema-qualified.
</para>
</listitem>
</varlistentry>
<term><replaceable class="parameter">table</replaceable></term>
<listitem>
<para>
- The name of an existing table.
+ The name (possibly schema-qualified) of an existing table.
</para>
</listitem>
</varlistentry>
<term><replaceable class="PARAMETER">name</replaceable></term>
<listitem>
<para>
- The name of an aggregate function to create.
+ The name (optionally schema-qualified) of an aggregate function to
+ create.
</para>
</listitem>
</varlistentry>
already provided, then <command>CREATE AGGREGATE</command>
can be used to provide the desired features.
</para>
+ <para>
+ If a schema name is given (for example, <literal>CREATE AGGREGATE
+ myschema.myagg ...</>) then the aggregate function is created in the
+ specified schema. Otherwise it is created in the current schema (the one
+ at the front of the search path; see <literal>CURRENT_SCHEMA()</>).
+ </para>
<para>
An aggregate function is identified by its name and input data type.
- Two aggregates can have the same name if they operate on different
- input types. The
+ Two aggregates in the same schema can have the same name if they operate on
+ different input types. The
name and input data type of an aggregate must also be distinct from
- the name and input data type of every ordinary function.
+ the name and input data type(s) of every ordinary function in the same
+ schema.
</para>
<para>
An aggregate function is made from one or two ordinary
<term><replaceable class="PARAMETER">relation</replaceable></term>
<listitem>
<para>
- Table name of the triggering relation.
+ The name (possibly schema-qualified) of the relation in which
+ the triggering events occur.
</para>
</listitem>
</varlistentry>
Description
</title>
<para>
- <command>CREATE CONSTRAINT TRIGGER</command> is used from inside of
+ <command>CREATE CONSTRAINT TRIGGER</command> is used within
<command>CREATE/ALTER TABLE</command> and by
<application>pg_dump</application> to create the special triggers for
referential integrity.
<term><replaceable class="parameter">domainname</replaceable></term>
<listitem>
<para>
- The name of a domain to be created.
+ The name (optionally schema-qualified) of a domain to be created.
</para>
</listitem>
</varlistentry>
<term><replaceable class="PARAMETER">data_type</replaceable></term>
<listitem>
<para>
- The data type of the domain. This may include array specifiers.
+ The underlying data type of the domain. This may include array
+ specifiers.
Refer to the <citetitle>User's Guide</citetitle> for further
information about data types and arrays.
</para>
</title>
<para>
- <command>CREATE DOMAIN</command> allows the user to register a new user data
- domain with PostgreSQL for use in the current data base. The
- user who defines a domain becomes its owner.
- <replaceable class="parameter">domainname</replaceable> is
- the name of the new type and must be unique within the
- types and domains defined for this database.
+ <command>CREATE DOMAIN</command> allows the user to register a new
+ data domain with <productname>PostgreSQL</> for use in the
+ current data base. The user who defines a domain becomes its owner.
+ </para>
+
+ <para>
+ If a schema name is given (for example, <literal>CREATE DOMAIN
+ myschema.mydomain ...</>) then the domain is created in the
+ specified schema. Otherwise it is created in the current schema (the one
+ at the front of the search path; see <literal>CURRENT_SCHEMA()</>).
+ The domain name must be unique among the types and domains existing
+ in its schema.
</para>
<para>
<listitem>
<para>
- The name of a function to create. The name need not be unique,
- because functions may be overloaded, but functions with the
- same name must have different argument types.
+ The name of a function to create. If a schema name is included,
+ then the function is created in the
+ specified schema. Otherwise it is created in the current schema (the
+ one at the front of the search path; see <literal>CURRENT_SCHEMA()</>).
+ The name of the new function must not match any existing function
+ with the same argument types in the same schema. However, functions of
+ different argument types may share a name (this is called
+ <firstterm>overloading</>).
</para>
</listitem>
</varlistentry>
</title>
<para>
A function that has one parameter and is named the same as its output
- datatype is considered to be a <firstterm>type coercion function</>:
- it can be invoked to convert a value of its input datatype into a value
+ datatype (including the schema name) is considered to be a <firstterm>type
+ coercion function</>: it can be invoked to convert a value of its input
+ datatype into a value
of its output datatype. For example,
<programlisting>
SELECT CAST(42 AS text);
<term><replaceable class="parameter">index_name</replaceable></term>
<listitem>
<para>
- The name of the index to be created.
+ The name of the index to be created. No schema name can be included
+ here; the index is always created in the same schema as its parent
+ table.
</para>
</listitem>
</varlistentry>
<term><replaceable class="parameter">table</replaceable></term>
<listitem>
<para>
- The name of the table to be indexed.
+ The name (possibly schema-qualified) of the table to be indexed.
</para>
</listitem>
</varlistentry>
<para>
All functions and operators used in an index definition must be
- <firstterm>cacheable</>, that is, their results must depend only on
+ <firstterm>immutable</>, that is, their results must depend only on
their input arguments and never on any outside influence (such as
the contents of another table or the current time). This restriction
ensures that the behavior of the index is well-defined. To use a
- user-defined function in an index, remember to mark the function cacheable
+ user-defined function in an index, remember to mark the function immutable
when you create it.
</para>
<listitem>
<para>
The operator to be defined. See below for allowable characters.
+ The name may be schema-qualified, for example
+ <literal>CREATE OPERATOR myschema.+ (...)</>.
</para>
</listitem>
</varlistentry>
<replaceable class="parameter">name</replaceable>.
The user who defines an operator becomes its owner.
</para>
+ <para>
+ If a schema name is given then the operator is created in the
+ specified schema. Otherwise it is created in the current schema (the one
+ at the front of the search path; see <literal>CURRENT_SCHEMA()</>).
+ </para>
+ <para>
+ Two operators in the same schema can have the same name if they operate on
+ different data types. This is called <firstterm>overloading</>. The
+ system will attempt to pick the intended operator based on the actual
+ input data types when there is ambiguity.
+ </para>
+
<para>
The operator <replaceable class="parameter">name</replaceable>
is a sequence of up to <symbol>NAMEDATALEN</>-1 (31 by default) characters
If specified, the sequence object is created only for this session,
and is automatically dropped on session exit.
Existing permanent sequences with the same name are not visible
- (in this session) while the temporary sequence exists.
+ (in this session) while the temporary sequence exists, unless
+ they are referenced with schema-qualified names.
</para>
</listitem>
</varlistentry>
<term><replaceable class="parameter">seqname</replaceable></term>
<listitem>
<para>
- The name of a sequence to be created.
+ The name (optionally schema-qualified) of a sequence to be created.
</para>
</listitem>
</varlistentry>
The generator will be owned by the user issuing the command.
</para>
+ <para>
+ If a schema name is given then the sequence is created in the
+ specified schema. Otherwise it is created in the current schema (the one
+ at the front of the search path; see <literal>CURRENT_SCHEMA()</>).
+ TEMP sequences exist in a special schema, so a schema name may not be
+ given when creating a TEMP sequence.
+ The sequence name must be distinct from the name of any other sequence,
+ table, index, or view in the same schema.
+ </para>
+
<para>
After a sequence is created, you use the functions
<function>nextval</function>,
command.
</para>
+ <para>
+ If a schema name is given (for example, <literal>CREATE TABLE
+ myschema.mytable ...</>) then the table is created in the
+ specified schema. Otherwise it is created in the current schema (the one
+ at the front of the search path; see <literal>CURRENT_SCHEMA()</>).
+ TEMP tables exist in a special schema, so a schema name may not be
+ given when creating a TEMP table.
+ The table name must be distinct from the name of any other table,
+ sequence, index, or view in the same schema.
+ </para>
+
<para>
<command>CREATE TABLE</command> also automatically creates a data
type that represents the tuple type (structure type) corresponding
to one row of the table. Therefore, tables cannot have the same
- name as any existing data type.
+ name as any existing data type in the same schema.
</para>
<para>
A table cannot have more than 1600 columns. (In practice, the
- effective limit is lower because of tuple-length constraints). A
- table cannot have the same name as a system catalog table.
+ effective limit is lower because of tuple-length constraints).
</para>
<para>
<para>
If specified, the table is created as a temporary table.
Temporary tables are automatically dropped at the end of a
- session. Existing persistent tables with the same name are not
- visible to the current session while the temporary table exists.
+ session. Existing permanent tables with the same name are not
+ visible to the current session while the temporary table exists,
+ unless they are referenced with schema-qualified names.
Any indexes created on a temporary table are automatically
temporary as well.
</para>
<term><replaceable class="PARAMETER">table_name</replaceable></term>
<listitem>
<para>
- The name of the table to be created.
+ The name (optionally schema-qualified) of the table to be created.
</para>
</listitem>
</varlistentry>
creating a view, but it is really quite different: it creates a new
table and evaluates the query just once to fill the new table
initially. The new table will not track subsequent changes to the
- source tables of the query. In contrast, a view re-evaluates the
- underlying <command>SELECT</command> statements whenever it is
+ source tables of the query. In contrast, a view re-evaluates its
+ defining <command>SELECT</command> statement whenever it is
queried.
</para>
</refsect1>
<listitem>
<para>
If specified, the table is created as a temporary table.
- Temporary tables are automatically dropped at the end of a
- session. Existing persistent tables with the same name are not
- visible to the current session while the temporary table exists.
- Any indexes created on a temporary table are automatically
- temporary as well.
- </para>
-
- <para>
- The <literal>LOCAL</literal> word is optional.
+ Refer to <xref linkend="sql-createtable"> for details.
</para>
</listitem>
</varlistentry>
<term><replaceable>table_name</replaceable></term>
<listitem>
<para>
- The name of the new table to be created. This table must not
- already exist. However, a temporary table can be created that
- has the same name as an existing permanent table.
+ The name (optionally schema-qualified) of the table to be created.
</para>
</listitem>
</varlistentry>
<term><replaceable class="parameter">typename</replaceable></term>
<listitem>
<para>
- The name of a type to be created.
+ The name (optionally schema-qualified) of a type to be created.
</para>
</listitem>
</varlistentry>
</title>
<para>
- <command>CREATE TYPE</command> allows the user to register a new user data
- type with PostgreSQL for use in the current data base. The
- user who defines a type becomes its owner.
- <replaceable class="parameter">typename</replaceable> is
- the name of the new type and must be unique within the
- types defined for this database.
+ <command>CREATE TYPE</command> allows the user to register a new data
+ type with <productname>PostgreSQL</> for use in the current data base.
+ The user who defines a type becomes its owner.
+ </para>
+
+ <para>
+ If a schema name is given then the type is created in the
+ specified schema. Otherwise it is created in the current schema (the one
+ at the front of the search path; see <literal>CURRENT_SCHEMA()</>).
+ The type name must be distinct from the name of any existing type or
+ domain in the same schema. (Because tables have associated datatypes,
+ type names also must not conflict with table names in the same schema.)
</para>
<para>
accessed like <literal>point[0]</> and <literal>point[1]</>.
Note that
this facility only works for fixed-length types whose internal form
- is exactly a sequence of N identical fields. A subscriptable
+ is exactly a sequence of N identical fixed-length fields. A subscriptable
variable-length type must have the generalized internal representation
used by <literal>array_in</> and <literal>array_out</>.
For historical reasons (i.e., this is clearly wrong but it's far too
<term><replaceable class="parameter">view</replaceable></term>
<listitem>
<para>
- The name of a view to be created.
+ The name (optionally schema-qualified) of a view to be created.
</para>
</listitem>
</varlistentry>
<term><replaceable class="parameter">query</replaceable></term>
<listitem>
<para>
- An SQL query which will provide the columns and rows of the view.
+ An SQL query (that is, a <command>SELECT</> statement)
+ which will provide the columns and rows of the view.
</para>
<para>
- Refer to the SELECT statement for more information
+ Refer to <xref linkend="sql-select"> for more information
about valid arguments.
</para>
</listitem>
Description
</title>
<para>
- <command>CREATE VIEW</command> will define a view of a table.
+ <command>CREATE VIEW</command> will define a view of a query.
The view is not physically materialized. Instead, a query
- rewrite retrieve rule is automatically generated to support
- retrieve operations on views.
+ rewrite rule (an <literal>ON SELECT</> rule) is automatically generated to
+ support SELECT operations on views.
+ </para>
+
+ <para>
+ If a schema name is given (for example, <literal>CREATE VIEW
+ myschema.myview ...</>) then the view is created in the
+ specified schema. Otherwise it is created in the current schema (the one
+ at the front of the search path; see <literal>CURRENT_SCHEMA()</>).
+ The view name must be distinct from the name of any other view, table,
+ sequence, or index in the same schema.
</para>
<refsect2 id="R2-SQL-CREATEVIEW-3">
<term><replaceable class="parameter">table</replaceable></term>
<listitem>
<para>
- The name of an existing table.
+ The name (optionally schema-qualified) of an existing table.
</para>
</listitem>
</varlistentry>
<term><replaceable class="parameter">name</replaceable></term>
<listitem>
<para>
- The name of an existing aggregate function.
+ The name (optionally schema-qualified) of an existing aggregate function.
</para>
</listitem>
</varlistentry>
<term><replaceable class="parameter">type</replaceable></term>
<listitem>
<para>
- The input data type of an existing aggregate function,
+ The input data type of the aggregate function,
or <literal>*</literal> if the function accepts any input type.
(Refer to the <citetitle>PostgreSQL User's Guide</citetitle> for
further information about data types.)
Description
</title>
<para>
- <command>DROP AGGREGATE</command> will remove all references to an existing
+ <command>DROP AGGREGATE</command> will delete an existing
aggregate definition. To execute this command the current
user must be the owner of the aggregate.
</para>
<term><replaceable class="PARAMETER">domainname</replaceable></term>
<listitem>
<para>
- The name of an existing domain.
+ The name (optionally schema-qualified) of an existing domain.
</para>
</listitem>
</varlistentry>
<term><replaceable class="parameter">name</replaceable></term>
<listitem>
<para>
- The name of an existing function.
+ The name (optionally schema-qualified) of an existing function.
</para>
</listitem>
</varlistentry>
<term><replaceable class="parameter">type</replaceable></term>
<listitem>
<para>
- The type of the function's parameters.
+ The type of a parameter of the function.
</para>
</listitem>
</varlistentry>
<term><replaceable class="PARAMETER">index_name</replaceable></term>
<listitem>
<para>
- The name of an index to remove.
+ The name (optionally schema-qualified) of an index to remove.
</para>
</listitem>
</varlistentry>
<term><replaceable class="parameter">id</replaceable></term>
<listitem>
<para>
- The identifier of an existing operator.
+ The identifier (optionally schema-qualified) of an existing operator.
</para>
</listitem>
</varlistentry>
for information on how to create operators.
</para>
<para>
- It is the user's responsibility to remove any access methods and
+ It is the user's responsibility to remove any access method
operator classes that rely on the deleted operator.
</para>
</refsect2>
<term><replaceable class="parameter">relation</replaceable></term>
<listitem>
<para>
- The name of the relation the rule applies to.
+ The name (optionally schema-qualified) of the relation the rule
+ applies to.
</para>
</listitem>
</varlistentry>
<term><replaceable class="PARAMETER">name</replaceable></term>
<listitem>
<para>
- The name of a sequence.
+ The name (optionally schema-qualified) of a sequence.
</para>
</listitem>
</varlistentry>
<term><replaceable class="PARAMETER">name</replaceable></term>
<listitem>
<para>
- The name of an existing table to drop.
+ The name (optionally schema-qualified) of an existing table to drop.
</para>
</listitem>
</varlistentry>
</title>
<para>
<command>DROP TABLE</command> removes tables from the database.
- Only its owner may destroy a table. A table
- may be emptied of rows, but not destroyed, by using <command>DELETE</command>.
+ Only its owner may destroy a table. A table may be emptied of rows, but not
+ destroyed, by using <command>DELETE</command>.
</para>
<para>
If a table being destroyed has secondary indexes on it,
they will be removed first. The removal of just a
secondary index will not affect the contents of the underlying table.
</para>
+ <para>
+ <command>DROP TABLE</command> will also remove any rules or triggers
+ that exist for the target table.
+ </para>
<refsect2 id="R2-SQL-DROPTABLE-3">
<refsect2info>
</variablelist>
<tip>
<para>
- At present, to remove a referenced view you must drop
+ At present, to remove a referencing view you must drop
it explicitly.
</para>
</tip>
<term><replaceable class="PARAMETER">table</replaceable></term>
<listitem>
<para>
- The name of a table.
+ The name (optionally schema-qualified) of a table.
</para>
</listitem>
</varlistentry>
Description
</title>
<para>
- <command>DROP TRIGGER</command> will remove all references to an existing
+ <command>DROP TRIGGER</command> will remove an existing
trigger definition. To execute this command the current
user must be the owner of the table for which the trigger is defined.
</para>
<term><replaceable class="PARAMETER">typename</replaceable></term>
<listitem>
<para>
- The name of an existing type.
+ The name (optionally schema-qualified) of an existing type.
</para>
</listitem>
</varlistentry>
<term><replaceable class="PARAMETER">name</replaceable></term>
<listitem>
<para>
- The name of an existing view.
+ The name (optionally schema-qualified) of an existing view.
</para>
</listitem>
</varlistentry>
Notes
</title>
<para>
- Refer to <command>CREATE VIEW</command>
+ Refer to <xref linkend="sql-createview">
for information on how to create views.
</para>
</refsect2>
Notes
</title>
<para>
- At present, to remove a referenced view from a
+ At present, to remove a referencing view from a
<productname>PostgreSQL</productname> database,
you must drop it explicitly.
</para>
<term><replaceable class="PARAMETER">table</replaceable></term>
<listitem>
<para>
- The name of an existing table.
+ The name (optionally schema-qualified) of an existing table.
</para>
</listitem>
</varlistentry>
<term><replaceable class="PARAMETER">name</replaceable></term>
<listitem>
<para>
- The name of an existing table to lock.
+ The name (optionally schema-qualified) of an existing table to lock.
</para>
</listitem>
</varlistentry>
<term><replaceable class="PARAMETER">name</replaceable></term>
<listitem>
<para>
- The name of the specific table/database/index to be be reindexed.
+ The name of the specific table/database/index to be reindexed.
+ Table and index names may be schema-qualified.
</para>
</listitem>
</varlistentry>
<term><replaceable class="PARAMETER">table_name</replaceable></term>
<listitem>
<para>
- The name of an existing table or view. If ONLY is specified, only that
- table is scanned. If ONLY is not specified, the table and all its
- descendant tables (if any) are scanned. * can be appended to the
- table name to indicate that descendant tables are to be scanned,
- but in the current version, this is the default behavior.
- (In releases before 7.1, ONLY was the default behavior.)
+ The name (optionally schema-qualified) of an existing table or view.
+ If <literal>ONLY</> is specified, only that table is scanned. If
+ <literal>ONLY</> is not specified, the table and all its descendant
+ tables (if any) are scanned. <literal>*</> can be appended to the
+ table name to indicate that descendant tables are to be scanned, but
+ in the current version, this is the default behavior. (In releases
+ before 7.1, <literal>ONLY</> was the default behavior.)
</para>
</listitem>
</varlistentry>
<term>TEMP</term>
<listitem>
<para>
- If TEMPORARY or TEMP is specified,
- the output table is created only within this session, and is
- automatically dropped on session exit.
- Existing permanent tables with the same name are not visible
- (in this session) while the temporary table exists.
- Any indexes created on a temporary table are automatically
- temporary as well.
+ If specified, the table is created as a temporary table.
+ Refer to <xref linkend="sql-createtable"> for details.
</para>
</listitem>
</varlistentry>
<term><replaceable class="PARAMETER">new_table</replaceable></term>
<listitem>
<para>
- The name of the new table to be created.
- This table must not already exist. However, a temporary table
- can be created that has the same name as an existing permanent
- table.
+ The name (optionally schema-qualified) of the table to be created.
</para>
</listitem>
</varlistentry>
<term><replaceable class="PARAMETER">name</replaceable></term>
<listitem>
<para>
- The name of the table to be truncated.
+ The name (optionally schema-qualified) of the table to be truncated.
</para>
</listitem>
</varlistentry>
<term><replaceable class="PARAMETER">table</replaceable></term>
<listitem>
<para>
- The name of an existing table.
+ The name (optionally schema-qualified) of an existing table.
</para>
</listitem>
</varlistentry>
<term><replaceable class="PARAMETER">table</replaceable></term>
<listitem>
<para>
- The name of a specific table to vacuum. Defaults to all tables
- in the current database.
+ The name (optionally schema-qualified) of a specific table to
+ vacuum. Defaults to all tables in the current database.
</para>
</listitem>
</varlistentry>
<para>
The entries in this <citetitle>Reference Manual</citetitle> are
- meant to provide in reasonable length an authorative, complete, and
- formal summary about the respective subjects. More information
+ meant to provide in reasonable length an authoritative, complete, and
+ formal summary about their respective subjects. More information
about the use of <productname>PostgreSQL</productname>, in
narrative, tutorial, or example form, may be found in other parts
of the <productname>PostgreSQL</productname> documentation set.
projects / users / bernd / postgres.git / commitdiff