rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
postgresql/doc/src/sgml/ref/create_table.sgml

1939 lines
77 KiB
Plaintext
Raw Normal View History

Complete merge of all old man page information. ecpg reference page still needs formatting.
1999-07-22 17:09:15 +02:00
<!--
Remove cvs keywords from all files.
2010-09-20 22:08:53 +02:00
doc/src/sgml/ref/create_table.sgml
Use PostgreSQL consistantly throughout docs. Before, usage was split evenly between Postgres and PostgreSQL.
2001-12-08 04:24:40 +01:00
PostgreSQL documentation
Complete merge of all old man page information. ecpg reference page still needs formatting.
1999-07-22 17:09:15 +02:00
-->
Minor updates for release. Split reference pages for CREATE TABLE AS and SELECT INTO to allow psgml (the emacs parser) to handle parsing.
1999-06-14 09:37:05 +02:00
<refentry id="SQL-CREATETABLE">
doc: Improve DocBook XML validity DocBook XML is superficially compatible with DocBook SGML but has a slightly stricter DTD that we have been violating in a few cases. Although XSLT doesn't care whether the document is valid, the style sheets don't necessarily process invalid documents correctly, so we need to work toward fixing this. This first commit moves the indexterms in refentry elements to an allowed position. It has no impact on the output.
2014-02-24 03:25:35 +01:00
<indexterm zone="sql-createtable">
<primary>CREATE TABLE</primary>
</indexterm>
Minor updates for release. Split reference pages for CREATE TABLE AS and SELECT INTO to allow psgml (the emacs parser) to handle parsing.
1999-06-14 09:37:05 +02:00
<refmeta>
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02:00
<refentrytitle>CREATE TABLE</refentrytitle>
Set SQL man pages to be section 7 by default, and only transform them to another section if required by the platform (instead of the old way of building them in section "l" and always transforming them to the platform-specific section). This speeds up the installation on common platforms, and it avoids some funny business with the man page tools and build process.
2008-11-14 11:22:48 +01:00
<manvolnum>7</manvolnum>
Minor updates for release. Split reference pages for CREATE TABLE AS and SELECT INTO to allow psgml (the emacs parser) to handle parsing.
1999-06-14 09:37:05 +02:00
<refmiscinfo>SQL - Language Statements</refmiscinfo>
</refmeta>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
Minor updates for release. Split reference pages for CREATE TABLE AS and SELECT INTO to allow psgml (the emacs parser) to handle parsing.
1999-06-14 09:37:05 +02:00
<refnamediv>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<refname>CREATE TABLE</refname>
<refpurpose>define a new table</refpurpose>
Clean up to ensure tag completion as required by the newest versions of Norm's Modular Style Sheets and jade/docbook. From Vince Vielhaber <vev@michvhf.com>.
1998-12-29 03:24:47 +01:00
</refnamediv>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
Minor updates for release. Split reference pages for CREATE TABLE AS and SELECT INTO to allow psgml (the emacs parser) to handle parsing.
1999-06-14 09:37:05 +02:00
<refsynopsisdiv>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<synopsis>
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } | UNLOGGED ] TABLE [ IF NOT EXISTS ] <replaceable class="parameter">table_name</replaceable> ( [
{ <replaceable class="parameter">column_name</replaceable> <replaceable class="parameter">data_type</replaceable> [ COLLATE <replaceable>collation</replaceable> ] [ <replaceable class="parameter">column_constraint</replaceable> [ ... ] ]
Brief note about sequence cache not being cleared in other backends. Actually clear the cache in the backend making the alteration. This follows in the footsteps of setval(). Rod Taylor
2003-06-12 09:49:43 +02:00
| <replaceable>table_constraint</replaceable>
Rename the internal structures of the CREATE TABLE (LIKE ...) facility The original implementation of this interpreted it as a kind of "inheritance" facility and named all the internal structures accordingly. This turned out to be very confusing, because it has nothing to do with the INHERITS feature. So rename all the internal parser infrastructure, update the comments, adjust the error messages, and split up the regression tests.
2012-01-07 13:58:13 +01:00
| LIKE <replaceable>source_table</replaceable> [ <replaceable>like_option</replaceable> ... ] }
Make an editorial pass over the reference pages.
2005-11-01 22:09:51 +01:00
[, ... ]
] )
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
[ INHERITS ( <replaceable>parent_table</replaceable> [, ... ] ) ]
Implement table partitioning. Table partitioning is like table inheritance and reuses much of the existing infrastructure, but there are some important differences. The parent is called a partitioned table and is always empty; it may not have indexes or non-inherited constraints, since those make no sense for a relation with no data of its own. The children are called partitions and contain all of the actual data. Each partition has an implicit partitioning constraint. Multiple inheritance is not allowed, and partitioning and inheritance can't be mixed. Partitions can't have extra columns and may not allow nulls unless the parent does. Tuples inserted into the parent are automatically routed to the correct partition, so tuple-routing ON INSERT triggers are not needed. Tuple routing isn't yet supported for partitions which are foreign tables, and it doesn't handle updates that cross partition boundaries. Currently, tables can be range-partitioned or list-partitioned. List partitioning is limited to a single column, but range partitioning can involve multiple columns. A partitioning "column" can be an expression. Because table partitioning is less general than table inheritance, it is hoped that it will be easier to reason about properties of partitions, and therefore that this will serve as a better foundation for a variety of possible optimizations, including query planner optimizations. The tuple routing based which this patch does based on the implicit partitioning constraints is an example of this, but it seems likely that many other useful optimizations are also possible. Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat, Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova, Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
[ PARTITION BY { RANGE | LIST } ( { <replaceable class="parameter">column_name</replaceable> | ( <replaceable class="parameter">expression</replaceable> ) } [ COLLATE <replaceable class="parameter">collation</replaceable> ] [ <replaceable class="parameter">opclass</replaceable> ] [, ... ] ) ]
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
[ WITH ( <replaceable class="parameter">storage_parameter</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] ) | WITH OIDS | WITHOUT OIDS ]
Code review for ON COMMIT patch. Make the actual on-commit action happen before commit, not after :-( --- the original coding is not only unsafe if an error occurs while it's processing, but it generates an invalid sequence of WAL entries. Resurrect 7.2 logic for deleting items when no longer needed. Use an enum instead of random macros. Editorialize on names used for routines and constants. Teach backend/nodes routines about new field in CreateTable struct. Add a regression test.
2002-11-11 23:19:25 +01:00
[ ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP } ]
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
[ TABLESPACE <replaceable class="parameter">tablespace_name</replaceable> ]
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } | UNLOGGED ] TABLE [ IF NOT EXISTS ] <replaceable class="parameter">table_name</replaceable>
OF <replaceable class="parameter">type_name</replaceable> [ (
{ <replaceable class="parameter">column_name</replaceable> [ WITH OPTIONS ] [ <replaceable class="parameter">column_constraint</replaceable> [ ... ] ]
Type table feature This adds the CREATE TABLE name OF type command, per SQL standard.
2010-01-29 00:21:13 +01:00
| <replaceable>table_constraint</replaceable> }
[, ... ]
) ]
Implement table partitioning. Table partitioning is like table inheritance and reuses much of the existing infrastructure, but there are some important differences. The parent is called a partitioned table and is always empty; it may not have indexes or non-inherited constraints, since those make no sense for a relation with no data of its own. The children are called partitions and contain all of the actual data. Each partition has an implicit partitioning constraint. Multiple inheritance is not allowed, and partitioning and inheritance can't be mixed. Partitions can't have extra columns and may not allow nulls unless the parent does. Tuples inserted into the parent are automatically routed to the correct partition, so tuple-routing ON INSERT triggers are not needed. Tuple routing isn't yet supported for partitions which are foreign tables, and it doesn't handle updates that cross partition boundaries. Currently, tables can be range-partitioned or list-partitioned. List partitioning is limited to a single column, but range partitioning can involve multiple columns. A partitioning "column" can be an expression. Because table partitioning is less general than table inheritance, it is hoped that it will be easier to reason about properties of partitions, and therefore that this will serve as a better foundation for a variety of possible optimizations, including query planner optimizations. The tuple routing based which this patch does based on the implicit partitioning constraints is an example of this, but it seems likely that many other useful optimizations are also possible. Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat, Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova, Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
[ PARTITION BY { RANGE | LIST } ( { <replaceable class="parameter">column_name</replaceable> | ( <replaceable class="parameter">expression</replaceable> ) } [ COLLATE <replaceable class="parameter">collation</replaceable> ] [ <replaceable class="parameter">opclass</replaceable> ] [, ... ] ) ]
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
[ WITH ( <replaceable class="parameter">storage_parameter</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] ) | WITH OIDS | WITHOUT OIDS ]
Implement table partitioning. Table partitioning is like table inheritance and reuses much of the existing infrastructure, but there are some important differences. The parent is called a partitioned table and is always empty; it may not have indexes or non-inherited constraints, since those make no sense for a relation with no data of its own. The children are called partitions and contain all of the actual data. Each partition has an implicit partitioning constraint. Multiple inheritance is not allowed, and partitioning and inheritance can't be mixed. Partitions can't have extra columns and may not allow nulls unless the parent does. Tuples inserted into the parent are automatically routed to the correct partition, so tuple-routing ON INSERT triggers are not needed. Tuple routing isn't yet supported for partitions which are foreign tables, and it doesn't handle updates that cross partition boundaries. Currently, tables can be range-partitioned or list-partitioned. List partitioning is limited to a single column, but range partitioning can involve multiple columns. A partitioning "column" can be an expression. Because table partitioning is less general than table inheritance, it is hoped that it will be easier to reason about properties of partitions, and therefore that this will serve as a better foundation for a variety of possible optimizations, including query planner optimizations. The tuple routing based which this patch does based on the implicit partitioning constraints is an example of this, but it seems likely that many other useful optimizations are also possible. Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat, Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova, Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
[ ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP } ]
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
[ TABLESPACE <replaceable class="parameter">tablespace_name</replaceable> ]
Implement table partitioning. Table partitioning is like table inheritance and reuses much of the existing infrastructure, but there are some important differences. The parent is called a partitioned table and is always empty; it may not have indexes or non-inherited constraints, since those make no sense for a relation with no data of its own. The children are called partitions and contain all of the actual data. Each partition has an implicit partitioning constraint. Multiple inheritance is not allowed, and partitioning and inheritance can't be mixed. Partitions can't have extra columns and may not allow nulls unless the parent does. Tuples inserted into the parent are automatically routed to the correct partition, so tuple-routing ON INSERT triggers are not needed. Tuple routing isn't yet supported for partitions which are foreign tables, and it doesn't handle updates that cross partition boundaries. Currently, tables can be range-partitioned or list-partitioned. List partitioning is limited to a single column, but range partitioning can involve multiple columns. A partitioning "column" can be an expression. Because table partitioning is less general than table inheritance, it is hoped that it will be easier to reason about properties of partitions, and therefore that this will serve as a better foundation for a variety of possible optimizations, including query planner optimizations. The tuple routing based which this patch does based on the implicit partitioning constraints is an example of this, but it seems likely that many other useful optimizations are also possible. Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat, Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova, Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } | UNLOGGED ] TABLE [ IF NOT EXISTS ] <replaceable class="parameter">table_name</replaceable>
PARTITION OF <replaceable class="parameter">parent_table</replaceable> [ (
{ <replaceable class="parameter">column_name</replaceable> [ WITH OPTIONS ] [ <replaceable class="parameter">column_constraint</replaceable> [ ... ] ]
Implement table partitioning. Table partitioning is like table inheritance and reuses much of the existing infrastructure, but there are some important differences. The parent is called a partitioned table and is always empty; it may not have indexes or non-inherited constraints, since those make no sense for a relation with no data of its own. The children are called partitions and contain all of the actual data. Each partition has an implicit partitioning constraint. Multiple inheritance is not allowed, and partitioning and inheritance can't be mixed. Partitions can't have extra columns and may not allow nulls unless the parent does. Tuples inserted into the parent are automatically routed to the correct partition, so tuple-routing ON INSERT triggers are not needed. Tuple routing isn't yet supported for partitions which are foreign tables, and it doesn't handle updates that cross partition boundaries. Currently, tables can be range-partitioned or list-partitioned. List partitioning is limited to a single column, but range partitioning can involve multiple columns. A partitioning "column" can be an expression. Because table partitioning is less general than table inheritance, it is hoped that it will be easier to reason about properties of partitions, and therefore that this will serve as a better foundation for a variety of possible optimizations, including query planner optimizations. The tuple routing based which this patch does based on the implicit partitioning constraints is an example of this, but it seems likely that many other useful optimizations are also possible. Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat, Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova, Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
| <replaceable>table_constraint</replaceable> }
[, ... ]
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
) ] { FOR VALUES <replaceable class="parameter">partition_bound_spec</replaceable> | DEFAULT }
Implement table partitioning. Table partitioning is like table inheritance and reuses much of the existing infrastructure, but there are some important differences. The parent is called a partitioned table and is always empty; it may not have indexes or non-inherited constraints, since those make no sense for a relation with no data of its own. The children are called partitions and contain all of the actual data. Each partition has an implicit partitioning constraint. Multiple inheritance is not allowed, and partitioning and inheritance can't be mixed. Partitions can't have extra columns and may not allow nulls unless the parent does. Tuples inserted into the parent are automatically routed to the correct partition, so tuple-routing ON INSERT triggers are not needed. Tuple routing isn't yet supported for partitions which are foreign tables, and it doesn't handle updates that cross partition boundaries. Currently, tables can be range-partitioned or list-partitioned. List partitioning is limited to a single column, but range partitioning can involve multiple columns. A partitioning "column" can be an expression. Because table partitioning is less general than table inheritance, it is hoped that it will be easier to reason about properties of partitions, and therefore that this will serve as a better foundation for a variety of possible optimizations, including query planner optimizations. The tuple routing based which this patch does based on the implicit partitioning constraints is an example of this, but it seems likely that many other useful optimizations are also possible. Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat, Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova, Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
[ PARTITION BY { RANGE | LIST } ( { <replaceable class="parameter">column_name</replaceable> | ( <replaceable class="parameter">expression</replaceable> ) } [ COLLATE <replaceable class="parameter">collation</replaceable> ] [ <replaceable class="parameter">opclass</replaceable> ] [, ... ] ) ]
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
[ WITH ( <replaceable class="parameter">storage_parameter</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] ) | WITH OIDS | WITHOUT OIDS ]
Type table feature This adds the CREATE TABLE name OF type command, per SQL standard.
2010-01-29 00:21:13 +01:00
[ ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP } ]
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
[ TABLESPACE <replaceable class="parameter">tablespace_name</replaceable> ]
Type table feature This adds the CREATE TABLE name OF type command, per SQL standard.
2010-01-29 00:21:13 +01:00
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
<phrase>where <replaceable class="parameter">column_constraint</replaceable> is:</phrase>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
[ CONSTRAINT <replaceable class="parameter">constraint_name</replaceable> ]
Support deferrable uniqueness constraints. The current implementation fires an AFTER ROW trigger for each tuple that looks like it might be non-unique according to the index contents at the time of insertion. This works well as long as there aren't many conflicts, but won't scale to massive unique-key reassignments. Improving that case is a TODO item. Dean Rasheed
2009-07-29 22:56:21 +02:00
{ NOT NULL |
NULL |
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
CHECK ( <replaceable class="parameter">expression</replaceable> ) [ NO INHERIT ] |
Reclassify DEFAULT as a column_constraint item in the CREATE TABLE syntax. This is how it was documented originally, but several years ago somebody decided that DEFAULT isn't a type of constraint. Well, the grammar thinks it is. The documentation was wrong in two ways: it alleged that DEFAULT had to appear before any other kind of constraint, and it alleged that you can't prefix a DEFAULT clause with a "CONSTRAINT name" clause, when in fact you can. (The latter behavior probably isn't SQL-standard, but our grammar has always allowed it.) This patch responds to Fujii Masao's observation that the ALTER TABLE documentation mistakenly implied that you couldn't include DEFAULT in ALTER TABLE ADD COLUMN; though this isn't the way he proposed fixing it.
2010-12-29 03:38:05 +01:00
DEFAULT <replaceable>default_expr</replaceable> |
Identity columns This is the SQL standard-conforming variant of PostgreSQL's serial columns. It fixes a few usability issues that serial columns have: - CREATE TABLE / LIKE copies default but refers to same sequence - cannot add/drop serialness with ALTER TABLE - dropping default does not drop sequence - need to grant separate privileges to sequence - other slight weirdnesses because serial is some kind of special macro Reviewed-by: Vitaly Burovoy <vitaly.burovoy@gmail.com>
2017-04-06 14:33:16 +02:00
GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY [ ( <replaceable>sequence_options</replaceable> ) ] |
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
UNIQUE <replaceable class="parameter">index_parameters</replaceable> |
PRIMARY KEY <replaceable class="parameter">index_parameters</replaceable> |
REFERENCES <replaceable class="parameter">reftable</replaceable> [ ( <replaceable class="parameter">refcolumn</replaceable> ) ] [ MATCH FULL | MATCH PARTIAL | MATCH SIMPLE ]
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
[ ON DELETE <replaceable class="parameter">action</replaceable> ] [ ON UPDATE <replaceable class="parameter">action</replaceable> ] }
[ DEFERRABLE | NOT DEFERRABLE ] [ INITIALLY DEFERRED | INITIALLY IMMEDIATE ]
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
<phrase>and <replaceable class="parameter">table_constraint</replaceable> is:</phrase>
Bring CREATE TABLE syntax synopsis into line with reality; update a bunch of old or poorly-worded documentation.
2001-01-12 06:06:40 +01:00
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
[ CONSTRAINT <replaceable class="parameter">constraint_name</replaceable> ]
{ CHECK ( <replaceable class="parameter">expression</replaceable> ) [ NO INHERIT ] |
UNIQUE ( <replaceable class="parameter">column_name</replaceable> [, ... ] ) <replaceable class="parameter">index_parameters</replaceable> |
PRIMARY KEY ( <replaceable class="parameter">column_name</replaceable> [, ... ] ) <replaceable class="parameter">index_parameters</replaceable> |
Add exclusion constraints, which generalize the concept of uniqueness to support any indexable commutative operator, not just equality. Two rows violate the exclusion constraint if "row1.col OP row2.col" is TRUE for each of the columns in the constraint. Jeff Davis, reviewed by Robert Haas
2009-12-07 06:22:23 +01:00
EXCLUDE [ USING <replaceable class="parameter">index_method</replaceable> ] ( <replaceable class="parameter">exclude_element</replaceable> WITH <replaceable class="parameter">operator</replaceable> [, ... ] ) <replaceable class="parameter">index_parameters</replaceable> [ WHERE ( <replaceable class="parameter">predicate</replaceable> ) ] |
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
FOREIGN KEY ( <replaceable class="parameter">column_name</replaceable> [, ... ] ) REFERENCES <replaceable class="parameter">reftable</replaceable> [ ( <replaceable class="parameter">refcolumn</replaceable> [, ... ] ) ]
More editing of reference pages.
2003-04-22 12:08:08 +02:00
[ MATCH FULL | MATCH PARTIAL | MATCH SIMPLE ] [ ON DELETE <replaceable class="parameter">action</replaceable> ] [ ON UPDATE <replaceable class="parameter">action</replaceable> ] }
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
[ DEFERRABLE | NOT DEFERRABLE ] [ INITIALLY DEFERRED | INITIALLY IMMEDIATE ]
Documentation fixes for FILLFACTOR patch. Minor other editorialization.
2006-07-04 20:07:24 +02:00
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
<phrase>and <replaceable class="parameter">like_option</replaceable> is:</phrase>
Add exclusion constraints, which generalize the concept of uniqueness to support any indexable commutative operator, not just equality. Two rows violate the exclusion constraint if "row1.col OP row2.col" is TRUE for each of the columns in the constraint. Jeff Davis, reviewed by Robert Haas
2009-12-07 06:22:23 +01:00
Identity columns This is the SQL standard-conforming variant of PostgreSQL's serial columns. It fixes a few usability issues that serial columns have: - CREATE TABLE / LIKE copies default but refers to same sequence - cannot add/drop serialness with ALTER TABLE - dropping default does not drop sequence - need to grant separate privileges to sequence - other slight weirdnesses because serial is some kind of special macro Reviewed-by: Vitaly Burovoy <vitaly.burovoy@gmail.com>
2017-04-06 14:33:16 +02:00
{ INCLUDING | EXCLUDING } { DEFAULTS | CONSTRAINTS | IDENTITY | INDEXES | STORAGE | COMMENTS | ALL }
Add exclusion constraints, which generalize the concept of uniqueness to support any indexable commutative operator, not just equality. Two rows violate the exclusion constraint if "row1.col OP row2.col" is TRUE for each of the columns in the constraint. Jeff Davis, reviewed by Robert Haas
2009-12-07 06:22:23 +01:00
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
<phrase>and <replaceable class="parameter">partition_bound_spec</replaceable> is:</phrase>
Implement table partitioning. Table partitioning is like table inheritance and reuses much of the existing infrastructure, but there are some important differences. The parent is called a partitioned table and is always empty; it may not have indexes or non-inherited constraints, since those make no sense for a relation with no data of its own. The children are called partitions and contain all of the actual data. Each partition has an implicit partitioning constraint. Multiple inheritance is not allowed, and partitioning and inheritance can't be mixed. Partitions can't have extra columns and may not allow nulls unless the parent does. Tuples inserted into the parent are automatically routed to the correct partition, so tuple-routing ON INSERT triggers are not needed. Tuple routing isn't yet supported for partitions which are foreign tables, and it doesn't handle updates that cross partition boundaries. Currently, tables can be range-partitioned or list-partitioned. List partitioning is limited to a single column, but range partitioning can involve multiple columns. A partitioning "column" can be an expression. Because table partitioning is less general than table inheritance, it is hoped that it will be easier to reason about properties of partitions, and therefore that this will serve as a better foundation for a variety of possible optimizations, including query planner optimizations. The tuple routing based which this patch does based on the implicit partitioning constraints is an example of this, but it seems likely that many other useful optimizations are also possible. Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat, Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova, Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
IN ( { <replaceable class="parameter">numeric_literal</replaceable> | <replaceable class="parameter">string_literal</replaceable> | NULL } [, ...] ) |
FROM ( { <replaceable class="parameter">numeric_literal</replaceable> | <replaceable class="parameter">string_literal</replaceable> | MINVALUE | MAXVALUE } [, ...] )
TO ( { <replaceable class="parameter">numeric_literal</replaceable> | <replaceable class="parameter">string_literal</replaceable> | MINVALUE | MAXVALUE } [, ...] )
Implement table partitioning. Table partitioning is like table inheritance and reuses much of the existing infrastructure, but there are some important differences. The parent is called a partitioned table and is always empty; it may not have indexes or non-inherited constraints, since those make no sense for a relation with no data of its own. The children are called partitions and contain all of the actual data. Each partition has an implicit partitioning constraint. Multiple inheritance is not allowed, and partitioning and inheritance can't be mixed. Partitions can't have extra columns and may not allow nulls unless the parent does. Tuples inserted into the parent are automatically routed to the correct partition, so tuple-routing ON INSERT triggers are not needed. Tuple routing isn't yet supported for partitions which are foreign tables, and it doesn't handle updates that cross partition boundaries. Currently, tables can be range-partitioned or list-partitioned. List partitioning is limited to a single column, but range partitioning can involve multiple columns. A partitioning "column" can be an expression. Because table partitioning is less general than table inheritance, it is hoped that it will be easier to reason about properties of partitions, and therefore that this will serve as a better foundation for a variety of possible optimizations, including query planner optimizations. The tuple routing based which this patch does based on the implicit partitioning constraints is an example of this, but it seems likely that many other useful optimizations are also possible. Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat, Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova, Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
<phrase><replaceable class="parameter">index_parameters</replaceable> in <literal>UNIQUE</literal>, <literal>PRIMARY KEY</literal>, and <literal>EXCLUDE</literal> constraints are:</phrase>
Documentation fixes for FILLFACTOR patch. Minor other editorialization.
2006-07-04 20:07:24 +02:00
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
[ WITH ( <replaceable class="parameter">storage_parameter</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] ) ]
[ USING INDEX TABLESPACE <replaceable class="parameter">tablespace_name</replaceable> ]
Add exclusion constraints, which generalize the concept of uniqueness to support any indexable commutative operator, not just equality. Two rows violate the exclusion constraint if "row1.col OP row2.col" is TRUE for each of the columns in the constraint. Jeff Davis, reviewed by Robert Haas
2009-12-07 06:22:23 +01:00
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
<phrase><replaceable class="parameter">exclude_element</replaceable> in an <literal>EXCLUDE</literal> constraint is:</phrase>
Add exclusion constraints, which generalize the concept of uniqueness to support any indexable commutative operator, not just equality. Two rows violate the exclusion constraint if "row1.col OP row2.col" is TRUE for each of the columns in the constraint. Jeff Davis, reviewed by Robert Haas
2009-12-07 06:22:23 +01:00
Make placeholders in SQL command help more consistent and precise To avoid divergent names on related pages, avoid ambiguities, and reduce translation work a little.
2012-06-22 00:06:14 +02:00
{ <replaceable class="parameter">column_name</replaceable> | ( <replaceable class="parameter">expression</replaceable> ) } [ <replaceable class="parameter">opclass</replaceable> ] [ ASC | DESC ] [ NULLS { FIRST | LAST } ]
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
</synopsis>
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
Minor updates for release. Split reference pages for CREATE TABLE AS and SELECT INTO to allow psgml (the emacs parser) to handle parsing.
1999-06-14 09:37:05 +02:00
</refsynopsisdiv>
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<refsect1 id="SQL-CREATETABLE-description">
<title>Description</title>
Complete merge of all old man page information. ecpg reference page still needs formatting.
1999-07-22 17:09:15 +02:00
Minor updates for release. Split reference pages for CREATE TABLE AS and SELECT INTO to allow psgml (the emacs parser) to handle parsing.
1999-06-14 09:37:05 +02:00
<para>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<command>CREATE TABLE</command> will create a new, initially empty table
in the current database. The table will be owned by the user issuing the
First version of files from Oliver Elphick.
1998-07-14 05:47:34 +02:00
command.
Clean up to ensure tag completion as required by the newest versions of Norm's Modular Style Sheets and jade/docbook. From Vince Vielhaber <vev@michvhf.com>.
1998-12-29 03:24:47 +01:00
</para>
Complete merge of all old man page information. ecpg reference page still needs formatting.
1999-07-22 17:09:15 +02:00
Update SQL-command reference pages for schema features.
2002-04-23 04:07:16 +02:00
<para>
If a schema name is given (for example, <literal>CREATE TABLE
Add support for temporary views, including documentation and regression tests. Contributed by Koju Iijima, review from Neil Conway, Gavin Sherry and Tom Lane. Also, fix error in description of WITH CHECK OPTION clause in the CREATE VIEW reference page: it should be "CASCADED", not "CASCADE".
2005-02-02 07:36:02 +01:00
myschema.mytable ...</>) then the table is created in the specified
schema. Otherwise it is created in the current schema. Temporary
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
tables exist in a special schema, so a schema name cannot be given
Add support for temporary views, including documentation and regression tests. Contributed by Koju Iijima, review from Neil Conway, Gavin Sherry and Tom Lane. Also, fix error in description of WITH CHECK OPTION clause in the CREATE VIEW reference page: it should be "CASCADED", not "CASCADE".
2005-02-02 07:36:02 +01:00
when creating a temporary table. The name of the table must be
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
distinct from the name of any other table, sequence, index, view,
or foreign table in the same schema.
Update SQL-command reference pages for schema features.
2002-04-23 04:07:16 +02:00
</para>
Complete merge of all old man page information. ecpg reference page still needs formatting.
1999-07-22 17:09:15 +02:00
<para>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<command>CREATE TABLE</command> also automatically creates a data
More editing of reference pages.
2003-04-22 12:08:08 +02:00
type that represents the composite type corresponding
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
to one row of the table. Therefore, tables cannot have the same
Update SQL-command reference pages for schema features.
2002-04-23 04:07:16 +02:00
name as any existing data type in the same schema.
Complete merge of all old man page information. ecpg reference page still needs formatting.
1999-07-22 17:09:15 +02:00
</para>
<para>
More minor updates and copy-editing.
2005-01-04 01:39:53 +01:00
The optional constraint clauses specify constraints (tests) that
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
new or updated rows must satisfy for an insert or update operation
More editing of reference pages.
2003-04-22 12:08:08 +02:00
to succeed. A constraint is an SQL object that helps define the
set of valid values in the table in various ways.
Bring CREATE TABLE syntax synopsis into line with reality; update a bunch of old or poorly-worded documentation.
2001-01-12 06:06:40 +01:00
</para>
Describe handling of multiply-inherited fields correctly.
2001-05-03 19:50:55 +02:00
<para>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
There are two ways to define constraints: table constraints and
column constraints. A column constraint is defined as part of a
column definition. A table constraint definition is not tied to a
particular column, and it can encompass more than one column.
Every column constraint can also be written as a table constraint;
More minor updates and copy-editing.
2005-01-04 01:39:53 +01:00
a column constraint is only a notational convenience for use when the
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
constraint only affects one column.
Describe handling of multiply-inherited fields correctly.
2001-05-03 19:50:55 +02:00
</para>
Add support for privileges on types This adds support for the more or less SQL-conforming USAGE privilege on types and domains. The intent is to be able restrict which users can create dependencies on types, which restricts the way in which owners can alter types. reviewed by Yeb Havinga
2011-12-19 23:05:19 +01:00
<para>
To be able to create a table, you must have <literal>USAGE</literal>
privilege on all column types or the type in the <literal>OF</literal>
clause, respectively.
</para>
Describe handling of multiply-inherited fields correctly.
2001-05-03 19:50:55 +02:00
</refsect1>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<refsect1>
<title>Parameters</title>
Describe handling of multiply-inherited fields correctly.
2001-05-03 19:50:55 +02:00
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<variablelist>
Describe handling of multiply-inherited fields correctly.
2001-05-03 19:50:55 +02:00
Documentation for logical decoding. Craig Ringer, Andres Freund, Christian Kruse, with edits by me.
2014-03-18 18:20:01 +01:00
<varlistentry id="SQL-CREATETABLE-TEMPORARY">
When a TIMESTAMP, TIME, or INTERVAL precision is specified larger than our implementation limits, do not issue an ERROR; instead issue a NOTICE and use the max supported value. Per pgsql-general discussion of 28-Apr, this is needed to allow easy porting from pre-7.3 releases where the limits were higher. Unrelated change in same area: accept GLOBAL TEMP/TEMPORARY as a synonym for TEMPORARY, as per pgsql-hackers discussion of 15-Apr. We previously rejected it, but that was based on a misreading of the spec --- SQL92's GLOBAL temp tables are really closer to what we have than their LOCAL ones.
2003-05-04 02:03:55 +02:00
<term><literal>TEMPORARY</> or <literal>TEMP</></term>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<listitem>
<para>
If specified, the table is created as a temporary table.
Temporary tables are automatically dropped at the end of a
This patch adds a new GUC var, "default_with_oids", which follows the proposal for eventually deprecating OIDs on user tables that I posted earlier to pgsql-hackers. pg_dump now always specifies WITH OIDS or WITHOUT OIDS when dumping a table. The documentation has been updated. Neil Conway
2003-12-01 23:08:02 +01:00
session, or optionally at the end of the current transaction
(see <literal>ON COMMIT</literal> below). 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.
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
</para>
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
Document that autovacuum cannot vacuum or analyze temporary tables.
2010-04-16 04:22:33 +02:00
<para>
The <link linkend="autovacuum">autovacuum daemon</link> cannot
access and therefore cannot vacuum or analyze temporary tables.
For this reason, appropriate vacuum and analyze operations should be
performed via session SQL commands. For example, if a temporary
table is going to be used in complex queries, it is wise to run
<command>ANALYZE</> on the temporary table after it is populated.
</para>
Use "TOAST table" in place of the vague, not-used-elsewhere phrase "supplementary storage table".
2010-05-13 20:54:18 +02:00
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<para>
When a TIMESTAMP, TIME, or INTERVAL precision is specified larger than our implementation limits, do not issue an ERROR; instead issue a NOTICE and use the max supported value. Per pgsql-general discussion of 28-Apr, this is needed to allow easy porting from pre-7.3 releases where the limits were higher. Unrelated change in same area: accept GLOBAL TEMP/TEMPORARY as a synonym for TEMPORARY, as per pgsql-hackers discussion of 15-Apr. We previously rejected it, but that was based on a misreading of the spec --- SQL92's GLOBAL temp tables are really closer to what we have than their LOCAL ones.
2003-05-04 02:03:55 +02:00
Optionally, <literal>GLOBAL</literal> or <literal>LOCAL</literal>
can be written before <literal>TEMPORARY</> or <literal>TEMP</>.
Deprecate use of GLOBAL and LOCAL in temp table creation. Aside from adjusting the documentation to say that these are deprecated, we now report a warning (not an error) for use of GLOBAL, since it seems fairly likely that we might change that to request SQL-spec-compliant temp table behavior in the foreseeable future. Although our handling of LOCAL is equally nonstandard, there is no evident interest in ever implementing SQL modules, and furthermore some other products interpret LOCAL as behaving the same way we do. So no expectation of change and no warning for LOCAL; but it still seems a good idea to deprecate writing it. Noah Misch
2012-06-13 23:48:42 +02:00
This presently makes no difference in <productname>PostgreSQL</>
and is deprecated; see
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<xref linkend="sql-createtable-compatibility"
endterm="sql-createtable-compatibility-title">.
</para>
</listitem>
</varlistentry>
Clean up to ensure tag completion as required by the newest versions of Norm's Modular Style Sheets and jade/docbook. From Vince Vielhaber <vev@michvhf.com>.
1998-12-29 03:24:47 +01:00
Documentation for logical decoding. Craig Ringer, Andres Freund, Christian Kruse, with edits by me.
2014-03-18 18:20:01 +01:00
<varlistentry id="SQL-CREATETABLE-UNLOGGED">
Support unlogged tables. The contents of an unlogged table are WAL-logged; thus, they are not available on standby servers and are truncated whenever the database system enters recovery. Indexes on unlogged tables are also unlogged. Unlogged GiST indexes are not currently supported.
2010-12-29 12:48:53 +01:00
<term><literal>UNLOGGED</></term>
<listitem>
<para>
If specified, the table is created as an unlogged table. Data written
to unlogged tables is not written to the write-ahead log (see <xref
linkend="wal">), which makes them considerably faster than ordinary
tables. However, they are not crash-safe: an unlogged table is
automatically truncated after a crash or unclean shutdown. The contents
of an unlogged table are also not replicated to standby servers.
Any indexes created on an unlogged table are automatically unlogged as
Support unlogged GiST index. The reason this wasn't supported before was that GiST indexes need an increasing sequence to detect concurrent page-splits. In a regular WAL- logged GiST index, the LSN of the page-split record is used for that purpose, and in a temporary index, we can get away with a backend-local counter. Neither of those methods works for an unlogged relation. To provide such an increasing sequence of numbers, create a "fake LSN" counter that is saved and restored across shutdowns. On recovery, unlogged relations are blown away, so the counter doesn't need to survive that either. Jeevan Chalke, based on discussions with Robert Haas, Tom Lane and me.
2013-02-11 21:50:15 +01:00
well.
Support unlogged tables. The contents of an unlogged table are WAL-logged; thus, they are not available on standby servers and are truncated whenever the database system enters recovery. Indexes on unlogged tables are also unlogged. Unlogged GiST indexes are not currently supported.
2010-12-29 12:48:53 +01:00
</para>
</listitem>
</varlistentry>
CREATE TABLE IF NOT EXISTS. Reviewed by Bernd Helmle.
2010-07-26 01:21:22 +02:00
<varlistentry>
<term><literal>IF NOT EXISTS</></term>
<listitem>
<para>
Do not throw an error if a relation with the same name already exists.
Remove tabs from sgml file.
2010-07-26 03:43:52 +02:00
A notice is issued in this case. Note that there is no guarantee that
the existing relation is anything like the one that would have been
created.
CREATE TABLE IF NOT EXISTS. Reviewed by Bernd Helmle.
2010-07-26 01:21:22 +02:00
</para>
</listitem>
</varlistentry>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<varlistentry>
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
<term><replaceable class="parameter">table_name</replaceable></term>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<listitem>
<para>
Update SQL-command reference pages for schema features.
2002-04-23 04:07:16 +02:00
The name (optionally schema-qualified) of the table to be created.
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
</para>
</listitem>
</varlistentry>
Editing and markup cleanup.
1998-09-22 17:48:03 +02:00
Type table feature This adds the CREATE TABLE name OF type command, per SQL standard.
2010-01-29 00:21:13 +01:00
<varlistentry>
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
<term><literal>OF <replaceable class="parameter">type_name</replaceable></literal></term>
Type table feature This adds the CREATE TABLE name OF type command, per SQL standard.
2010-01-29 00:21:13 +01:00
<listitem>
<para>
Creates a <firstterm>typed table</firstterm>, which takes its
structure from the specified composite type (name optionally
schema-qualified). A typed table is tied to its type; for
example the table will be dropped if the type is dropped
(with <literal>DROP TYPE ... CASCADE</literal>).
</para>
<para>
When a typed table is created, then the data types of the
columns are determined by the underlying composite type and are
not specified by the <literal>CREATE TABLE</literal> command.
But the <literal>CREATE TABLE</literal> command can add defaults
and constraints to the table and can specify storage parameters.
</para>
</listitem>
</varlistentry>
doc: first draft of Postgres 10 release notes
2017-04-25 03:26:33 +02:00
<varlistentry id="SQL-CREATETABLE-PARTITION">
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
<term><literal>PARTITION OF <replaceable class="parameter">parent_table</replaceable> { FOR VALUES <replaceable class="parameter">partition_bound_spec</replaceable> | DEFAULT }</literal></term>
Implement table partitioning. Table partitioning is like table inheritance and reuses much of the existing infrastructure, but there are some important differences. The parent is called a partitioned table and is always empty; it may not have indexes or non-inherited constraints, since those make no sense for a relation with no data of its own. The children are called partitions and contain all of the actual data. Each partition has an implicit partitioning constraint. Multiple inheritance is not allowed, and partitioning and inheritance can't be mixed. Partitions can't have extra columns and may not allow nulls unless the parent does. Tuples inserted into the parent are automatically routed to the correct partition, so tuple-routing ON INSERT triggers are not needed. Tuple routing isn't yet supported for partitions which are foreign tables, and it doesn't handle updates that cross partition boundaries. Currently, tables can be range-partitioned or list-partitioned. List partitioning is limited to a single column, but range partitioning can involve multiple columns. A partitioning "column" can be an expression. Because table partitioning is less general than table inheritance, it is hoped that it will be easier to reason about properties of partitions, and therefore that this will serve as a better foundation for a variety of possible optimizations, including query planner optimizations. The tuple routing based which this patch does based on the implicit partitioning constraints is an example of this, but it seems likely that many other useful optimizations are also possible. Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat, Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova, Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
<listitem>
<para>
Docs: improve CREATE TABLE ref page's discussion of partition bounds. Clarify in the syntax synopsis that partition bound values must be exactly numeric literals or string literals; previously it said "bound_literal" which was defined nowhere. Replace confusing --- and, I think, incorrect in detail --- definition of how range bounds work with a reference to row-wise comparison plus a concrete example (which I stole from Robert Haas). Minor copy-editing in the same area. Discussion: https://postgr.es/m/30475.1496005465@sss.pgh.pa.us Discussion: https://postgr.es/m/28106.1496041449@sss.pgh.pa.us
2017-06-07 23:23:38 +02:00
Creates the table as a <firstterm>partition</firstterm> of the specified
Allow a partitioned table to have a default partition. Any tuples that don't route to any other partition will route to the default partition. Jeevan Ladhe, Beena Emerson, Ashutosh Bapat, Rahila Syed, and Robert Haas, with review and testing at various stages by (at least) Rushabh Lathia, Keith Fiske, Amit Langote, Amul Sul, Rajkumar Raghuanshi, Sven Kunze, Kyotaro Horiguchi, Thom Brown, Rafia Sabih, and Dilip Kumar. Discussion: http://postgr.es/m/CAH2L28tbN4SYyhS7YV1YBWcitkqbhSWfQCy0G=apRcC_PEO-bg@mail.gmail.com Discussion: http://postgr.es/m/CAOG9ApEYj34fWMcvBMBQ-YtqR9fTdXhdN82QEKG0SVZ6zeL1xg@mail.gmail.com
2017-09-08 23:28:04 +02:00
parent table. The table can be created either as a partition for specific
values using <literal>FOR VALUES</literal> or as a default partition
using <literal>DEFAULT</literal>.
Implement table partitioning. Table partitioning is like table inheritance and reuses much of the existing infrastructure, but there are some important differences. The parent is called a partitioned table and is always empty; it may not have indexes or non-inherited constraints, since those make no sense for a relation with no data of its own. The children are called partitions and contain all of the actual data. Each partition has an implicit partitioning constraint. Multiple inheritance is not allowed, and partitioning and inheritance can't be mixed. Partitions can't have extra columns and may not allow nulls unless the parent does. Tuples inserted into the parent are automatically routed to the correct partition, so tuple-routing ON INSERT triggers are not needed. Tuple routing isn't yet supported for partitions which are foreign tables, and it doesn't handle updates that cross partition boundaries. Currently, tables can be range-partitioned or list-partitioned. List partitioning is limited to a single column, but range partitioning can involve multiple columns. A partitioning "column" can be an expression. Because table partitioning is less general than table inheritance, it is hoped that it will be easier to reason about properties of partitions, and therefore that this will serve as a better foundation for a variety of possible optimizations, including query planner optimizations. The tuple routing based which this patch does based on the implicit partitioning constraints is an example of this, but it seems likely that many other useful optimizations are also possible. Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat, Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova, Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
</para>
<para>
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
The <replaceable class="parameter">partition_bound_spec</replaceable>
Docs: improve CREATE TABLE ref page's discussion of partition bounds. Clarify in the syntax synopsis that partition bound values must be exactly numeric literals or string literals; previously it said "bound_literal" which was defined nowhere. Replace confusing --- and, I think, incorrect in detail --- definition of how range bounds work with a reference to row-wise comparison plus a concrete example (which I stole from Robert Haas). Minor copy-editing in the same area. Discussion: https://postgr.es/m/30475.1496005465@sss.pgh.pa.us Discussion: https://postgr.es/m/28106.1496041449@sss.pgh.pa.us
2017-06-07 23:23:38 +02:00
must correspond to the partitioning method and partition key of the
parent table, and must not overlap with any existing partition of that
parent. The form with <literal>IN</> is used for list partitioning,
while the form with <literal>FROM</> and <literal>TO</> is used for
range partitioning.
Implement table partitioning. Table partitioning is like table inheritance and reuses much of the existing infrastructure, but there are some important differences. The parent is called a partitioned table and is always empty; it may not have indexes or non-inherited constraints, since those make no sense for a relation with no data of its own. The children are called partitions and contain all of the actual data. Each partition has an implicit partitioning constraint. Multiple inheritance is not allowed, and partitioning and inheritance can't be mixed. Partitions can't have extra columns and may not allow nulls unless the parent does. Tuples inserted into the parent are automatically routed to the correct partition, so tuple-routing ON INSERT triggers are not needed. Tuple routing isn't yet supported for partitions which are foreign tables, and it doesn't handle updates that cross partition boundaries. Currently, tables can be range-partitioned or list-partitioned. List partitioning is limited to a single column, but range partitioning can involve multiple columns. A partitioning "column" can be an expression. Because table partitioning is less general than table inheritance, it is hoped that it will be easier to reason about properties of partitions, and therefore that this will serve as a better foundation for a variety of possible optimizations, including query planner optimizations. The tuple routing based which this patch does based on the implicit partitioning constraints is an example of this, but it seems likely that many other useful optimizations are also possible. Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat, Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova, Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
</para>
Tidy up the CREATE TABLE documentation for partitioning. Remove some <note> tags that make this too "loud". Fix some typos. Amit Langote, with a few minor corrections by me Discussion: http://postgr.es/m/a6f99cdb-21e7-1d65-1381-91f2cfa156e2@lab.ntt.co.jp
2017-03-27 17:00:09 +02:00
<para>
Docs: improve CREATE TABLE ref page's discussion of partition bounds. Clarify in the syntax synopsis that partition bound values must be exactly numeric literals or string literals; previously it said "bound_literal" which was defined nowhere. Replace confusing --- and, I think, incorrect in detail --- definition of how range bounds work with a reference to row-wise comparison plus a concrete example (which I stole from Robert Haas). Minor copy-editing in the same area. Discussion: https://postgr.es/m/30475.1496005465@sss.pgh.pa.us Discussion: https://postgr.es/m/28106.1496041449@sss.pgh.pa.us
2017-06-07 23:23:38 +02:00
Each of the values specified in
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
the <replaceable class="parameter">partition_bound_spec</> is
Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition bounds. Previously, UNBOUNDED meant no lower bound when used in the FROM list, and no upper bound when used in the TO list, which was OK for single-column range partitioning, but problematic with multiple columns. For example, an upper bound of (10.0, UNBOUNDED) would not be collocated with a lower bound of (10.0, UNBOUNDED), thus making it difficult or impossible to define contiguous multi-column range partitions in some cases. Fix this by using MINVALUE and MAXVALUE instead of UNBOUNDED to represent a partition column that is unbounded below or above respectively. This syntax removes any ambiguity, and ensures that if one partition's lower bound equals another partition's upper bound, then the partitions are contiguous. Also drop the constraint prohibiting finite values after an unbounded column, and just document the fact that any values after MINVALUE or MAXVALUE are ignored. Previously it was necessary to repeat UNBOUNDED multiple times, which was needlessly verbose. Note: Forces a post-PG 10 beta2 initdb. Report by Amul Sul, original patch by Amit Langote with some additional hacking by me. Discussion: https://postgr.es/m/CAAJ_b947mowpLdxL3jo3YLKngRjrq9+Ej4ymduQTfYR+8=YAYQ@mail.gmail.com
2017-07-21 10:20:47 +02:00
a literal, <literal>NULL</literal>, <literal>MINVALUE</literal>, or
<literal>MAXVALUE</literal>. Each literal value must be either a
numeric constant that is coercible to the corresponding partition key
column's type, or a string literal that is valid input for that type.
Docs: improve CREATE TABLE ref page's discussion of partition bounds. Clarify in the syntax synopsis that partition bound values must be exactly numeric literals or string literals; previously it said "bound_literal" which was defined nowhere. Replace confusing --- and, I think, incorrect in detail --- definition of how range bounds work with a reference to row-wise comparison plus a concrete example (which I stole from Robert Haas). Minor copy-editing in the same area. Discussion: https://postgr.es/m/30475.1496005465@sss.pgh.pa.us Discussion: https://postgr.es/m/28106.1496041449@sss.pgh.pa.us
2017-06-07 23:23:38 +02:00
</para>
<para>
When creating a list partition, <literal>NULL</literal> can be
specified to signify that the partition allows the partition key
column to be null. However, there cannot be more than one such
list partition for a given parent table. <literal>NULL</literal>
cannot be specified for range partitions.
Tidy up the CREATE TABLE documentation for partitioning. Remove some <note> tags that make this too "loud". Fix some typos. Amit Langote, with a few minor corrections by me Discussion: http://postgr.es/m/a6f99cdb-21e7-1d65-1381-91f2cfa156e2@lab.ntt.co.jp
2017-03-27 17:00:09 +02:00
</para>
<para>
When creating a range partition, the lower bound specified with
<literal>FROM</literal> is an inclusive bound, whereas the upper
bound specified with <literal>TO</literal> is an exclusive bound.
That is, the values specified in the <literal>FROM</literal> list
Docs: improve CREATE TABLE ref page's discussion of partition bounds. Clarify in the syntax synopsis that partition bound values must be exactly numeric literals or string literals; previously it said "bound_literal" which was defined nowhere. Replace confusing --- and, I think, incorrect in detail --- definition of how range bounds work with a reference to row-wise comparison plus a concrete example (which I stole from Robert Haas). Minor copy-editing in the same area. Discussion: https://postgr.es/m/30475.1496005465@sss.pgh.pa.us Discussion: https://postgr.es/m/28106.1496041449@sss.pgh.pa.us
2017-06-07 23:23:38 +02:00
are valid values of the corresponding partition key columns for this
partition, whereas those in the <literal>TO</literal> list are
not. Note that this statement must be understood according to the
rules of row-wise comparison (<xref linkend="row-wise-comparison">).
For example, given <literal>PARTITION BY RANGE (x,y)</>, a partition
bound <literal>FROM (1, 2) TO (3, 4)</literal>
allows <literal>x=1</> with any <literal>y&gt;=2</>,
<literal>x=2</> with any non-null <literal>y</>,
and <literal>x=3</> with any <literal>y&lt;4</>.
Tidy up the CREATE TABLE documentation for partitioning. Remove some <note> tags that make this too "loud". Fix some typos. Amit Langote, with a few minor corrections by me Discussion: http://postgr.es/m/a6f99cdb-21e7-1d65-1381-91f2cfa156e2@lab.ntt.co.jp
2017-03-27 17:00:09 +02:00
</para>
<para>
Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition bounds. Previously, UNBOUNDED meant no lower bound when used in the FROM list, and no upper bound when used in the TO list, which was OK for single-column range partitioning, but problematic with multiple columns. For example, an upper bound of (10.0, UNBOUNDED) would not be collocated with a lower bound of (10.0, UNBOUNDED), thus making it difficult or impossible to define contiguous multi-column range partitions in some cases. Fix this by using MINVALUE and MAXVALUE instead of UNBOUNDED to represent a partition column that is unbounded below or above respectively. This syntax removes any ambiguity, and ensures that if one partition's lower bound equals another partition's upper bound, then the partitions are contiguous. Also drop the constraint prohibiting finite values after an unbounded column, and just document the fact that any values after MINVALUE or MAXVALUE are ignored. Previously it was necessary to repeat UNBOUNDED multiple times, which was needlessly verbose. Note: Forces a post-PG 10 beta2 initdb. Report by Amul Sul, original patch by Amit Langote with some additional hacking by me. Discussion: https://postgr.es/m/CAAJ_b947mowpLdxL3jo3YLKngRjrq9+Ej4ymduQTfYR+8=YAYQ@mail.gmail.com
2017-07-21 10:20:47 +02:00
The special values <literal>MINVALUE</> and <literal>MAXVALUE</>
may be used when creating a range partition to indicate that there
is no lower or upper bound on the column's value. For example, a
partition defined using <literal>FROM (MINVALUE) TO (10)</> allows
any values less than 10, and a partition defined using
<literal>FROM (10) TO (MAXVALUE)</> allows any values greater than
or equal to 10.
</para>
<para>
When creating a range partition involving more than one column, it
can also make sense to use <literal>MAXVALUE</> as part of the lower
bound, and <literal>MINVALUE</> as part of the upper bound. For
example, a partition defined using
<literal>FROM (0, MAXVALUE) TO (10, MAXVALUE)</> allows any rows
where the first partition key column is greater than 0 and less than
or equal to 10. Similarly, a partition defined using
<literal>FROM ('a', MINVALUE) TO ('b', MINVALUE)</> allows any rows
where the first partition key column starts with "a".
</para>
<para>
After a MINVALUE/MAXVALUE bound, allow only more of the same. In the old syntax, which used UNBOUNDED, we had a similar restriction, but commit d363d42bb9a4399a0207bd3b371c966e22e06bd3, which changed the syntax, eliminated it. Put it back. Patch by me, reviewed by Dean Rasheed. Discussion: http://postgr.es/m/CA+Tgmobs+pLPC27tS3gOpEAxAffHrq5w509cvkwTf9pF6cWYbg@mail.gmail.com
2017-09-16 03:15:55 +02:00
Note that if <literal>MINVALUE</> or <literal>MAXVALUE</> is used for
one column of a partitioning bound, the same value must be used for all
subsequent columns. For example, <literal>(10, MINVALUE, 0)</> is not
a valid bound; you should write <literal>(10, MINVALUE, MINVALUE)</>.
Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition bounds. Previously, UNBOUNDED meant no lower bound when used in the FROM list, and no upper bound when used in the TO list, which was OK for single-column range partitioning, but problematic with multiple columns. For example, an upper bound of (10.0, UNBOUNDED) would not be collocated with a lower bound of (10.0, UNBOUNDED), thus making it difficult or impossible to define contiguous multi-column range partitions in some cases. Fix this by using MINVALUE and MAXVALUE instead of UNBOUNDED to represent a partition column that is unbounded below or above respectively. This syntax removes any ambiguity, and ensures that if one partition's lower bound equals another partition's upper bound, then the partitions are contiguous. Also drop the constraint prohibiting finite values after an unbounded column, and just document the fact that any values after MINVALUE or MAXVALUE are ignored. Previously it was necessary to repeat UNBOUNDED multiple times, which was needlessly verbose. Note: Forces a post-PG 10 beta2 initdb. Report by Amul Sul, original patch by Amit Langote with some additional hacking by me. Discussion: https://postgr.es/m/CAAJ_b947mowpLdxL3jo3YLKngRjrq9+Ej4ymduQTfYR+8=YAYQ@mail.gmail.com
2017-07-21 10:20:47 +02:00
</para>
<para>
Also note that some element types, such as <literal>timestamp</>,
have a notion of "infinity", which is just another value that can
be stored. This is different from <literal>MINVALUE</> and
<literal>MAXVALUE</>, which are not real values that can be stored,
but rather they are ways of saying that the value is unbounded.
<literal>MAXVALUE</> can be thought of as being greater than any
other value, including "infinity" and <literal>MINVALUE</> as being
less than any other value, including "minus infinity". Thus the range
<literal>FROM ('infinity') TO (MAXVALUE)</> is not an empty range; it
allows precisely one value to be stored &mdash; "infinity".
Tidy up the CREATE TABLE documentation for partitioning. Remove some <note> tags that make this too "loud". Fix some typos. Amit Langote, with a few minor corrections by me Discussion: http://postgr.es/m/a6f99cdb-21e7-1d65-1381-91f2cfa156e2@lab.ntt.co.jp
2017-03-27 17:00:09 +02:00
</para>
Improve CREATE TABLE documentation of partitioning Amit Langote, with corrections by me
2017-02-10 09:59:37 +01:00
Allow a partitioned table to have a default partition. Any tuples that don't route to any other partition will route to the default partition. Jeevan Ladhe, Beena Emerson, Ashutosh Bapat, Rahila Syed, and Robert Haas, with review and testing at various stages by (at least) Rushabh Lathia, Keith Fiske, Amit Langote, Amul Sul, Rajkumar Raghuanshi, Sven Kunze, Kyotaro Horiguchi, Thom Brown, Rafia Sabih, and Dilip Kumar. Discussion: http://postgr.es/m/CAH2L28tbN4SYyhS7YV1YBWcitkqbhSWfQCy0G=apRcC_PEO-bg@mail.gmail.com Discussion: http://postgr.es/m/CAOG9ApEYj34fWMcvBMBQ-YtqR9fTdXhdN82QEKG0SVZ6zeL1xg@mail.gmail.com
2017-09-08 23:28:04 +02:00
<para>
If <literal>DEFAULT</literal> is specified, the table will be
created as a default partition of the parent table. The parent can
either be a list or range partitioned table. A partition key value
not fitting into any other partition of the given parent will be
routed to the default partition. There can be only one default
partition for a given parent table.
</para>
<para>
When a table has an existing <literal>DEFAULT</literal> partition and
a new partition is added to it, the existing default partition must
be scanned to verify that it does not contain any rows which properly
belong in the new partition. If the default partition contains a
large number of rows, this may be slow. The scan will be skipped if
the default partition is a foreign table or if it has a constraint which
proves that it cannot contain rows which should be placed in the new
partition.
</para>
Implement table partitioning. Table partitioning is like table inheritance and reuses much of the existing infrastructure, but there are some important differences. The parent is called a partitioned table and is always empty; it may not have indexes or non-inherited constraints, since those make no sense for a relation with no data of its own. The children are called partitions and contain all of the actual data. Each partition has an implicit partitioning constraint. Multiple inheritance is not allowed, and partitioning and inheritance can't be mixed. Partitions can't have extra columns and may not allow nulls unless the parent does. Tuples inserted into the parent are automatically routed to the correct partition, so tuple-routing ON INSERT triggers are not needed. Tuple routing isn't yet supported for partitions which are foreign tables, and it doesn't handle updates that cross partition boundaries. Currently, tables can be range-partitioned or list-partitioned. List partitioning is limited to a single column, but range partitioning can involve multiple columns. A partitioning "column" can be an expression. Because table partitioning is less general than table inheritance, it is hoped that it will be easier to reason about properties of partitions, and therefore that this will serve as a better foundation for a variety of possible optimizations, including query planner optimizations. The tuple routing based which this patch does based on the implicit partitioning constraints is an example of this, but it seems likely that many other useful optimizations are also possible. Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat, Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova, Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
<para>
Make partitions automatically inherit OIDs. Previously, if the parent was specified as WITH OIDS, each child also had to be explicitly specified as WITH OIDS. Amit Langote, per a report from Simon Riggs. Some additional work on the documentation changes by me. Discussion: http://postgr.es/m/CANP8+jJBpWocfKrbJcaf3iBt9E3U=WPE_NC8YE6rye+YJ1sYnQ@mail.gmail.com
2017-02-19 16:59:27 +01:00
A partition must have the same column names and types as the partitioned
table to which it belongs. If the parent is specified <literal>WITH
OIDS</literal> then all partitions must have OIDs; the parent's OID
column will be inherited by all partitions just like any other column.
Modifications to the column names or types of a partitioned table, or
the addition or removal of an OID column, will automatically propagate
to all partitions. <literal>CHECK</> constraints will be inherited
automatically by every partition, but an individual partition may specify
additional <literal>CHECK</> constraints; additional constraints with
the same name and condition as in the parent will be merged with the
parent constraint. Defaults may be specified separately for each
partition.
Implement table partitioning. Table partitioning is like table inheritance and reuses much of the existing infrastructure, but there are some important differences. The parent is called a partitioned table and is always empty; it may not have indexes or non-inherited constraints, since those make no sense for a relation with no data of its own. The children are called partitions and contain all of the actual data. Each partition has an implicit partitioning constraint. Multiple inheritance is not allowed, and partitioning and inheritance can't be mixed. Partitions can't have extra columns and may not allow nulls unless the parent does. Tuples inserted into the parent are automatically routed to the correct partition, so tuple-routing ON INSERT triggers are not needed. Tuple routing isn't yet supported for partitions which are foreign tables, and it doesn't handle updates that cross partition boundaries. Currently, tables can be range-partitioned or list-partitioned. List partitioning is limited to a single column, but range partitioning can involve multiple columns. A partitioning "column" can be an expression. Because table partitioning is less general than table inheritance, it is hoped that it will be easier to reason about properties of partitions, and therefore that this will serve as a better foundation for a variety of possible optimizations, including query planner optimizations. The tuple routing based which this patch does based on the implicit partitioning constraints is an example of this, but it seems likely that many other useful optimizations are also possible. Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat, Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova, Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
</para>
<para>
Rows inserted into a partitioned table will be automatically routed to
the correct partition. If no suitable partition exists, an error will
Docs: improve CREATE TABLE ref page's discussion of partition bounds. Clarify in the syntax synopsis that partition bound values must be exactly numeric literals or string literals; previously it said "bound_literal" which was defined nowhere. Replace confusing --- and, I think, incorrect in detail --- definition of how range bounds work with a reference to row-wise comparison plus a concrete example (which I stole from Robert Haas). Minor copy-editing in the same area. Discussion: https://postgr.es/m/30475.1496005465@sss.pgh.pa.us Discussion: https://postgr.es/m/28106.1496041449@sss.pgh.pa.us
2017-06-07 23:23:38 +02:00
occur. Also, if updating a row in a given partition would require it
to move to another partition due to new partition key values, an error
will occur.
Implement table partitioning. Table partitioning is like table inheritance and reuses much of the existing infrastructure, but there are some important differences. The parent is called a partitioned table and is always empty; it may not have indexes or non-inherited constraints, since those make no sense for a relation with no data of its own. The children are called partitions and contain all of the actual data. Each partition has an implicit partitioning constraint. Multiple inheritance is not allowed, and partitioning and inheritance can't be mixed. Partitions can't have extra columns and may not allow nulls unless the parent does. Tuples inserted into the parent are automatically routed to the correct partition, so tuple-routing ON INSERT triggers are not needed. Tuple routing isn't yet supported for partitions which are foreign tables, and it doesn't handle updates that cross partition boundaries. Currently, tables can be range-partitioned or list-partitioned. List partitioning is limited to a single column, but range partitioning can involve multiple columns. A partitioning "column" can be an expression. Because table partitioning is less general than table inheritance, it is hoped that it will be easier to reason about properties of partitions, and therefore that this will serve as a better foundation for a variety of possible optimizations, including query planner optimizations. The tuple routing based which this patch does based on the implicit partitioning constraints is an example of this, but it seems likely that many other useful optimizations are also possible. Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat, Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova, Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
</para>
<para>
Make partitions automatically inherit OIDs. Previously, if the parent was specified as WITH OIDS, each child also had to be explicitly specified as WITH OIDS. Amit Langote, per a report from Simon Riggs. Some additional work on the documentation changes by me. Discussion: http://postgr.es/m/CANP8+jJBpWocfKrbJcaf3iBt9E3U=WPE_NC8YE6rye+YJ1sYnQ@mail.gmail.com
2017-02-19 16:59:27 +01:00
Operations such as TRUNCATE which normally affect a table and all of its
inheritance children will cascade to all partitions, but may also be
performed on an individual partition. Note that dropping a partition
with <literal>DROP TABLE</literal> requires taking an <literal>ACCESS
EXCLUSIVE</literal> lock on the parent table.
Implement table partitioning. Table partitioning is like table inheritance and reuses much of the existing infrastructure, but there are some important differences. The parent is called a partitioned table and is always empty; it may not have indexes or non-inherited constraints, since those make no sense for a relation with no data of its own. The children are called partitions and contain all of the actual data. Each partition has an implicit partitioning constraint. Multiple inheritance is not allowed, and partitioning and inheritance can't be mixed. Partitions can't have extra columns and may not allow nulls unless the parent does. Tuples inserted into the parent are automatically routed to the correct partition, so tuple-routing ON INSERT triggers are not needed. Tuple routing isn't yet supported for partitions which are foreign tables, and it doesn't handle updates that cross partition boundaries. Currently, tables can be range-partitioned or list-partitioned. List partitioning is limited to a single column, but range partitioning can involve multiple columns. A partitioning "column" can be an expression. Because table partitioning is less general than table inheritance, it is hoped that it will be easier to reason about properties of partitions, and therefore that this will serve as a better foundation for a variety of possible optimizations, including query planner optimizations. The tuple routing based which this patch does based on the implicit partitioning constraints is an example of this, but it seems likely that many other useful optimizations are also possible. Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat, Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova, Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
</para>
</listitem>
</varlistentry>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<varlistentry>
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
<term><replaceable class="parameter">column_name</replaceable></term>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<listitem>
<para>
The name of a column to be created in the new table.
</para>
</listitem>
</varlistentry>
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<varlistentry>
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
<term><replaceable class="parameter">data_type</replaceable></term>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<listitem>
<para>
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
The data type of the column. This can include array
More minor updates and copy-editing.
2005-01-04 01:39:53 +01:00
specifiers. For more information on the data types supported by
Add a few more xrefs, where they seemed appropriate: for example, refer to the discussion of planner statistics in the documentation for the default_statistics_target GUC var.
2004-03-01 18:58:39 +01:00
<productname>PostgreSQL</productname>, refer to <xref
linkend="datatype">.
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
</para>
</listitem>
</varlistentry>
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
Per-column collation support This adds collation support for columns and domains, a COLLATE clause to override it per expression, and B-tree index support. Peter Eisentraut reviewed by Pavel Stehule, Itagaki Takahiro, Robert Haas, Noah Misch
2011-02-08 22:04:18 +01:00
<varlistentry>
<term><literal>COLLATE <replaceable>collation</replaceable></literal></term>
<listitem>
<para>
Remove collation information from TypeName, where it does not belong. The initial collations patch treated a COLLATE spec as part of a TypeName, following what can only be described as brain fade on the part of the SQL committee. It's a lot more reasonable to treat COLLATE as a syntactically separate object, so that it can be added in only the productions where it actually belongs, rather than needing to reject it in a boatload of places where it doesn't belong (something the original patch mostly failed to do). In addition this change lets us meet the spec's requirement to allow COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly behavior for constructs such as "foo::type COLLATE collation". To do this, pull collation information out of TypeName and put it in ColumnDef instead, thus reverting most of the collation-related changes in parse_type.c's API. I made one additional structural change, which was to use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd nodes. This provides enough room to get rid of the "transform" wart in AlterTableCmd too, since the ColumnDef can carry the USING expression easily enough. Also fix some other minor bugs that have crept in in the same areas, like failure to copy recently-added fields of ColumnDef in copyfuncs.c. While at it, document the formerly secret ability to specify a collation in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about what the default collation selection will be when COLLATE is omitted. BTW, the three-parameter form of format_type() should go away too, since it just contributes to the confusion in this area; but I'll do that in a separate patch.
2011-03-10 04:38:52 +01:00
The <literal>COLLATE</> clause assigns a collation to
the column (which must be of a collatable data type).
If not specified, the column data type's default collation is used.
Per-column collation support This adds collation support for columns and domains, a COLLATE clause to override it per expression, and B-tree index support. Peter Eisentraut reviewed by Pavel Stehule, Itagaki Takahiro, Robert Haas, Noah Misch
2011-02-08 22:04:18 +01:00
</para>
</listitem>
</varlistentry>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<varlistentry>
<term><literal>INHERITS ( <replaceable>parent_table</replaceable> [, ... ] )</literal></term>
<listitem>
<para>
The optional <literal>INHERITS</> clause specifies a list of
tables from which the new table automatically inherits all
Allow foreign tables to participate in inheritance. Foreign tables can now be inheritance children, or parents. Much of the system was already ready for this, but we had to fix a few things of course, mostly in the area of planner and executor handling of row locks. As side effects of this, allow foreign tables to have NOT VALID CHECK constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to disallow these things would've required bizarre and inconsistent special cases in inheritance behavior. Since foreign tables don't enforce CHECK constraints anyway, a NOT VALID one is a complete no-op, but that doesn't mean we shouldn't allow it. And it's possible that some FDWs might have use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops for most. An additional change in support of this is that when a ModifyTable node has multiple target tables, they will all now be explicitly identified in EXPLAIN output, for example: Update on pt1 (cost=0.00..321.05 rows=3541 width=46) Update on pt1 Foreign Update on ft1 Foreign Update on ft2 Update on child3 -> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46) -> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46) -> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46) -> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46) This was done mainly to provide an unambiguous place to attach "Remote SQL" fields, but it is useful for inherited updates even when no foreign tables are involved. Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
columns. Parent tables can be plain tables or foreign tables.
Clean up rather poor description of the difference between INHERITS and LIKE. Per gripe from Patrick Samson.
2004-03-22 17:18:50 +01:00
</para>
<para>
Use of <literal>INHERITS</> creates a persistent relationship
between the new child table and its parent table(s). Schema
modifications to the parent(s) normally propagate to children
as well, and by default the data of the child table is included in
scans of the parent(s).
</para>
<para>
If the same column name exists in more than one parent
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
table, an error is reported unless the data types of the columns
match in each of the parent tables. If there is no conflict,
then the duplicate columns are merged to form a single column in
the new table. If the column name list of the new table
Clean up rather poor description of the difference between INHERITS and LIKE. Per gripe from Patrick Samson.
2004-03-22 17:18:50 +01:00
contains a column name that is also inherited, the data type must
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
likewise match the inherited column(s), and the column
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
definitions are merged into one. If the
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
new table explicitly specifies a default value for the column,
this default overrides any defaults from inherited declarations
of the column. Otherwise, any parents that specify default
values for the column must all specify the same default, or an
error will be reported.
</para>
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
Allow foreign tables to participate in inheritance. Foreign tables can now be inheritance children, or parents. Much of the system was already ready for this, but we had to fix a few things of course, mostly in the area of planner and executor handling of row locks. As side effects of this, allow foreign tables to have NOT VALID CHECK constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to disallow these things would've required bizarre and inconsistent special cases in inheritance behavior. Since foreign tables don't enforce CHECK constraints anyway, a NOT VALID one is a complete no-op, but that doesn't mean we shouldn't allow it. And it's possible that some FDWs might have use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops for most. An additional change in support of this is that when a ModifyTable node has multiple target tables, they will all now be explicitly identified in EXPLAIN output, for example: Update on pt1 (cost=0.00..321.05 rows=3541 width=46) Update on pt1 Foreign Update on ft1 Foreign Update on ft2 Update on child3 -> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46) -> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46) -> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46) -> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46) This was done mainly to provide an unambiguous place to attach "Remote SQL" fields, but it is useful for inherited updates even when no foreign tables are involved. Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
<para>
<literal>CHECK</> constraints are merged in essentially the same way as
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
columns: if multiple parent tables and/or the new table definition
contain identically-named <literal>CHECK</> constraints, these
constraints must all have the same check expression, or an error will be
reported. Constraints having the same name and expression will
Recast "ONLY" column CHECK constraints as NO INHERIT The original syntax wasn't universally loved, and it didn't allow its usage in CREATE TABLE, only ALTER TABLE. It now works everywhere, and it also allows using ALTER TABLE ONLY to add an uninherited CHECK constraint, per discussion. The pg_constraint column has accordingly been renamed connoinherit. This commit partly reverts some of the changes in 61d81bd28dbec65a6b144e0cd3d0bfe25913c3ac, particularly some pg_dump and psql bits, because now pg_get_constraintdef includes the necessary NO INHERIT within the constraint definition. Author: Nikhil Sontakke Some tweaks by me
2012-04-21 04:46:20 +02:00
be merged into one copy. A constraint marked <literal>NO INHERIT</> in a
parent will not be considered. Notice that an unnamed <literal>CHECK</>
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
constraint in the new table will never be merged, since a unique name
will always be chosen for it.
</para>
CREATE LIKE INCLUDING COMMENTS and STORAGE, and INCLUDING ALL shortcut. Itagaki Takahiro.
2009-10-12 21:49:24 +02:00
<para>
Code review for LIKE INCLUDING patch --- clean up some cosmetic and not so cosmetic stuff.
2009-10-13 02:53:08 +02:00
Column <literal>STORAGE</> settings are also copied from parent tables.
CREATE LIKE INCLUDING COMMENTS and STORAGE, and INCLUDING ALL shortcut. Itagaki Takahiro.
2009-10-12 21:49:24 +02:00
</para>
Identity columns This is the SQL standard-conforming variant of PostgreSQL's serial columns. It fixes a few usability issues that serial columns have: - CREATE TABLE / LIKE copies default but refers to same sequence - cannot add/drop serialness with ALTER TABLE - dropping default does not drop sequence - need to grant separate privileges to sequence - other slight weirdnesses because serial is some kind of special macro Reviewed-by: Vitaly Burovoy <vitaly.burovoy@gmail.com>
2017-04-06 14:33:16 +02:00
<para>
If a column in the parent table is an identity column, that property is
not inherited. A column in the child table can be declared identity
column if desired.
</para>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
</listitem>
</varlistentry>
Complete merge of all old man page information. ecpg reference page still needs formatting.
1999-07-22 17:09:15 +02:00
Implement table partitioning. Table partitioning is like table inheritance and reuses much of the existing infrastructure, but there are some important differences. The parent is called a partitioned table and is always empty; it may not have indexes or non-inherited constraints, since those make no sense for a relation with no data of its own. The children are called partitions and contain all of the actual data. Each partition has an implicit partitioning constraint. Multiple inheritance is not allowed, and partitioning and inheritance can't be mixed. Partitions can't have extra columns and may not allow nulls unless the parent does. Tuples inserted into the parent are automatically routed to the correct partition, so tuple-routing ON INSERT triggers are not needed. Tuple routing isn't yet supported for partitions which are foreign tables, and it doesn't handle updates that cross partition boundaries. Currently, tables can be range-partitioned or list-partitioned. List partitioning is limited to a single column, but range partitioning can involve multiple columns. A partitioning "column" can be an expression. Because table partitioning is less general than table inheritance, it is hoped that it will be easier to reason about properties of partitions, and therefore that this will serve as a better foundation for a variety of possible optimizations, including query planner optimizations. The tuple routing based which this patch does based on the implicit partitioning constraints is an example of this, but it seems likely that many other useful optimizations are also possible. Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat, Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova, Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
<varlistentry>
<term><literal>PARTITION BY { RANGE | LIST } ( { <replaceable class="parameter">column_name</replaceable> | ( <replaceable class="parameter">expression</replaceable> ) } [ <replaceable class="parameter">opclass</replaceable> ] [, ...] ) </literal></term>
<listitem>
<para>
The optional <literal>PARTITION BY</literal> clause specifies a strategy
of partitioning the table. The table thus created is called a
<firstterm>partitioned</firstterm> table. The parenthesized list of
columns or expressions forms the <firstterm>partition key</firstterm>
for the table. When using range partitioning, the partition key can
doc: Fix typos and other minor issues Author: Alexander Lakhin <exclusion@gmail.com>
2017-09-02 05:34:12 +02:00
include multiple columns or expressions (up to 32, but this limit can be
altered when building <productname>PostgreSQL</productname>), but for
Improve CREATE TABLE documentation of partitioning Amit Langote, with corrections by me
2017-02-10 09:59:37 +01:00
list partitioning, the partition key must consist of a single column or
Documentation spell checking and markup improvements
2017-06-18 20:01:45 +02:00
expression. If no B-tree operator class is specified when creating a
partitioned table, the default B-tree operator class for the datatype will
Improve CREATE TABLE documentation of partitioning Amit Langote, with corrections by me
2017-02-10 09:59:37 +01:00
be used. If there is none, an error will be reported.
Implement table partitioning. Table partitioning is like table inheritance and reuses much of the existing infrastructure, but there are some important differences. The parent is called a partitioned table and is always empty; it may not have indexes or non-inherited constraints, since those make no sense for a relation with no data of its own. The children are called partitions and contain all of the actual data. Each partition has an implicit partitioning constraint. Multiple inheritance is not allowed, and partitioning and inheritance can't be mixed. Partitions can't have extra columns and may not allow nulls unless the parent does. Tuples inserted into the parent are automatically routed to the correct partition, so tuple-routing ON INSERT triggers are not needed. Tuple routing isn't yet supported for partitions which are foreign tables, and it doesn't handle updates that cross partition boundaries. Currently, tables can be range-partitioned or list-partitioned. List partitioning is limited to a single column, but range partitioning can involve multiple columns. A partitioning "column" can be an expression. Because table partitioning is less general than table inheritance, it is hoped that it will be easier to reason about properties of partitions, and therefore that this will serve as a better foundation for a variety of possible optimizations, including query planner optimizations. The tuple routing based which this patch does based on the implicit partitioning constraints is an example of this, but it seems likely that many other useful optimizations are also possible. Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat, Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova, Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
</para>
<para>
A partitioned table is divided into sub-tables (called partitions),
which are created using separate <literal>CREATE TABLE</> commands.
The partitioned table is itself empty. A data row inserted into the
table is routed to a partition based on the value of columns or
expressions in the partition key. If no existing partition matches
the values in the new row, an error will be reported.
</para>
<para>
Partitioned tables do not support <literal>UNIQUE</literal>,
<literal>PRIMARY KEY</literal>, <literal>EXCLUDE</literal>, or
<literal>FOREIGN KEY</literal> constraints; however, you can define
these constraints on individual partitions.
</para>
</listitem>
</varlistentry>
More minor updates and copy-editing.
2005-01-04 01:39:53 +01:00
<varlistentry>
Rename the internal structures of the CREATE TABLE (LIKE ...) facility The original implementation of this interpreted it as a kind of "inheritance" facility and named all the internal structures accordingly. This turned out to be very confusing, because it has nothing to do with the INHERITS feature. So rename all the internal parser infrastructure, update the comments, adjust the error messages, and split up the regression tests.
2012-01-07 13:58:13 +01:00
<term><literal>LIKE <replaceable>source_table</replaceable> [ <replaceable>like_option</replaceable> ... ]</literal></term>
More minor updates and copy-editing.
2005-01-04 01:39:53 +01:00
<listitem>
<para>
The <literal>LIKE</literal> clause specifies a table from which
the new table automatically copies all column names, their data types,
and their not-null constraints.
</para>
<para>
Unlike <literal>INHERITS</literal>, the new table and original table
are completely decoupled after creation is complete. Changes to the
original table will not be applied to the new table, and it is not
possible to include data of the new table in scans of the original
table.
</para>
<para>
Improve documentation about CREATE TABLE ... LIKE. The docs failed to explain that LIKE INCLUDING INDEXES would not preserve the names of indexes and associated constraints. Also, it wasn't mentioned that EXCLUDE constraints would be copied by this option. The latter oversight seems enough of a documentation bug to justify back-patching. In passing, do some minor copy-editing in the same area, and add an entry for LIKE under "Compatibility", since it's not exactly a faithful implementation of the standard's feature. Discussion: <20160728151154.AABE64016B@smtp.hushmail.com>
2016-07-28 19:26:58 +02:00
Default expressions for the copied column definitions will be copied
only if <literal>INCLUDING DEFAULTS</literal> is specified. The
Editorialization for the additions to the CREATE TABLE reference page made as part of the recent INCLUDING CONSTRAINTS patch. The text could stand further improvement, but this is at least a step in the right direction.
2006-06-29 00:01:52 +02:00
default behavior is to exclude default expressions, resulting in the
copied columns in the new table having null defaults.
Improve documentation about CREATE TABLE ... LIKE. The docs failed to explain that LIKE INCLUDING INDEXES would not preserve the names of indexes and associated constraints. Also, it wasn't mentioned that EXCLUDE constraints would be copied by this option. The latter oversight seems enough of a documentation bug to justify back-patching. In passing, do some minor copy-editing in the same area, and add an entry for LIKE under "Compatibility", since it's not exactly a faithful implementation of the standard's feature. Discussion: <20160728151154.AABE64016B@smtp.hushmail.com>
2016-07-28 19:26:58 +02:00
Note that copying defaults that call database-modification functions,
such as <function>nextval</>, may create a functional linkage between
the original and new tables.
More minor updates and copy-editing.
2005-01-04 01:39:53 +01:00
</para>
Identity columns This is the SQL standard-conforming variant of PostgreSQL's serial columns. It fixes a few usability issues that serial columns have: - CREATE TABLE / LIKE copies default but refers to same sequence - cannot add/drop serialness with ALTER TABLE - dropping default does not drop sequence - need to grant separate privileges to sequence - other slight weirdnesses because serial is some kind of special macro Reviewed-by: Vitaly Burovoy <vitaly.burovoy@gmail.com>
2017-04-06 14:33:16 +02:00
<para>
Any identity specifications of copied column definitions will only be
copied if <literal>INCLUDING IDENTITY</literal> is specified. A new
sequence is created for each identity column of the new table, separate
from the sequences associated with the old table.
</para>
Add INCLUDING CONSTRAINTS to CREATE TABLE LIKE. Greg Stark
2006-06-27 05:43:20 +02:00
<para>
Editorialization for the additions to the CREATE TABLE reference page made as part of the recent INCLUDING CONSTRAINTS patch. The text could stand further improvement, but this is at least a step in the right direction.
2006-06-29 00:01:52 +02:00
Not-null constraints are always copied to the new table.
Clarify documentation that primary key and unique constraints are copied for CREATE TABLE LIKE ... INCLUDING INDEXES. Per report from david.sahagian@emc.com
2012-08-26 22:33:11 +02:00
<literal>CHECK</literal> constraints will be copied only if
Remove whitespace from end of lines
2013-05-31 03:05:07 +02:00
<literal>INCLUDING CONSTRAINTS</literal> is specified.
Clarify documentation that primary key and unique constraints are copied for CREATE TABLE LIKE ... INCLUDING INDEXES. Per report from david.sahagian@emc.com
2012-08-26 22:33:11 +02:00
No distinction is made between column constraints and table
constraints.
Implement CREATE TABLE LIKE ... INCLUDING INDEXES. Patch from NikhilS, based in part on an earlier patch from Trevor Hardcastle, and reviewed by myself.
2007-07-17 07:02:03 +02:00
</para>
Improve documentation about CREATE TABLE ... LIKE. The docs failed to explain that LIKE INCLUDING INDEXES would not preserve the names of indexes and associated constraints. Also, it wasn't mentioned that EXCLUDE constraints would be copied by this option. The latter oversight seems enough of a documentation bug to justify back-patching. In passing, do some minor copy-editing in the same area, and add an entry for LIKE under "Compatibility", since it's not exactly a faithful implementation of the standard's feature. Discussion: <20160728151154.AABE64016B@smtp.hushmail.com>
2016-07-28 19:26:58 +02:00
<para>
Indexes, <literal>PRIMARY KEY</>, <literal>UNIQUE</>,
and <literal>EXCLUDE</> constraints on the original table will be
created on the new table only if <literal>INCLUDING INDEXES</literal>
is specified. Names for the new indexes and constraints are
chosen according to the default rules, regardless of how the originals
were named. (This behavior avoids possible duplicate-name failures for
the new indexes.)
</para>
<para>
<literal>STORAGE</> settings for the copied column definitions will be
copied only if <literal>INCLUDING STORAGE</literal> is specified. The
Code review for LIKE INCLUDING patch --- clean up some cosmetic and not so cosmetic stuff.
2009-10-13 02:53:08 +02:00
default behavior is to exclude <literal>STORAGE</> settings, resulting
in the copied columns in the new table having type-specific default
settings. For more on <literal>STORAGE</> settings, see
<xref linkend="storage-toast">.
CREATE LIKE INCLUDING COMMENTS and STORAGE, and INCLUDING ALL shortcut. Itagaki Takahiro.
2009-10-12 21:49:24 +02:00
</para>
<para>
Code review for LIKE INCLUDING patch --- clean up some cosmetic and not so cosmetic stuff.
2009-10-13 02:53:08 +02:00
Comments for the copied columns, constraints, and indexes
Improve documentation about CREATE TABLE ... LIKE. The docs failed to explain that LIKE INCLUDING INDEXES would not preserve the names of indexes and associated constraints. Also, it wasn't mentioned that EXCLUDE constraints would be copied by this option. The latter oversight seems enough of a documentation bug to justify back-patching. In passing, do some minor copy-editing in the same area, and add an entry for LIKE under "Compatibility", since it's not exactly a faithful implementation of the standard's feature. Discussion: <20160728151154.AABE64016B@smtp.hushmail.com>
2016-07-28 19:26:58 +02:00
will be copied only if <literal>INCLUDING COMMENTS</literal>
Code review for LIKE INCLUDING patch --- clean up some cosmetic and not so cosmetic stuff.
2009-10-13 02:53:08 +02:00
is specified. The default behavior is to exclude comments, resulting in
the copied columns and constraints in the new table having no comments.
CREATE LIKE INCLUDING COMMENTS and STORAGE, and INCLUDING ALL shortcut. Itagaki Takahiro.
2009-10-12 21:49:24 +02:00
</para>
Improve documentation about CREATE TABLE ... LIKE. The docs failed to explain that LIKE INCLUDING INDEXES would not preserve the names of indexes and associated constraints. Also, it wasn't mentioned that EXCLUDE constraints would be copied by this option. The latter oversight seems enough of a documentation bug to justify back-patching. In passing, do some minor copy-editing in the same area, and add an entry for LIKE under "Compatibility", since it's not exactly a faithful implementation of the standard's feature. Discussion: <20160728151154.AABE64016B@smtp.hushmail.com>
2016-07-28 19:26:58 +02:00
<para>
<literal>INCLUDING ALL</literal> is an abbreviated form of
Identity columns This is the SQL standard-conforming variant of PostgreSQL's serial columns. It fixes a few usability issues that serial columns have: - CREATE TABLE / LIKE copies default but refers to same sequence - cannot add/drop serialness with ALTER TABLE - dropping default does not drop sequence - need to grant separate privileges to sequence - other slight weirdnesses because serial is some kind of special macro Reviewed-by: Vitaly Burovoy <vitaly.burovoy@gmail.com>
2017-04-06 14:33:16 +02:00
<literal>INCLUDING DEFAULTS INCLUDING IDENTITY INCLUDING CONSTRAINTS INCLUDING INDEXES INCLUDING STORAGE INCLUDING COMMENTS</literal>.
CREATE LIKE INCLUDING COMMENTS and STORAGE, and INCLUDING ALL shortcut. Itagaki Takahiro.
2009-10-12 21:49:24 +02:00
</para>
Add INCLUDING CONSTRAINTS to CREATE TABLE LIKE. Greg Stark
2006-06-27 05:43:20 +02:00
<para>
Improve documentation about CREATE TABLE ... LIKE. The docs failed to explain that LIKE INCLUDING INDEXES would not preserve the names of indexes and associated constraints. Also, it wasn't mentioned that EXCLUDE constraints would be copied by this option. The latter oversight seems enough of a documentation bug to justify back-patching. In passing, do some minor copy-editing in the same area, and add an entry for LIKE under "Compatibility", since it's not exactly a faithful implementation of the standard's feature. Discussion: <20160728151154.AABE64016B@smtp.hushmail.com>
2016-07-28 19:26:58 +02:00
Note that unlike <literal>INHERITS</literal>, columns and
Code review for LIKE INCLUDING patch --- clean up some cosmetic and not so cosmetic stuff.
2009-10-13 02:53:08 +02:00
constraints copied by <literal>LIKE</> are not merged with similarly
named columns and constraints.
Add INCLUDING CONSTRAINTS to CREATE TABLE LIKE. Greg Stark
2006-06-27 05:43:20 +02:00
If the same name is specified explicitly or in another
Documentation spell checking and markup improvements
2013-05-21 03:13:13 +02:00
<literal>LIKE</literal> clause, an error is signaled.
Add INCLUDING CONSTRAINTS to CREATE TABLE LIKE. Greg Stark
2006-06-27 05:43:20 +02:00
</para>
Support CREATE TABLE (LIKE ...) with foreign tables and views Composite types are not yet supported, because parserOpenTable() rejects them.
2012-01-10 20:46:29 +01:00
<para>
Improve documentation about CREATE TABLE ... LIKE. The docs failed to explain that LIKE INCLUDING INDEXES would not preserve the names of indexes and associated constraints. Also, it wasn't mentioned that EXCLUDE constraints would be copied by this option. The latter oversight seems enough of a documentation bug to justify back-patching. In passing, do some minor copy-editing in the same area, and add an entry for LIKE under "Compatibility", since it's not exactly a faithful implementation of the standard's feature. Discussion: <20160728151154.AABE64016B@smtp.hushmail.com>
2016-07-28 19:26:58 +02:00
The <literal>LIKE</literal> clause can also be used to copy column
definitions from views, foreign tables, or composite types.
Inapplicable options (e.g., <literal>INCLUDING INDEXES</literal> from
a view) are ignored.
Support CREATE TABLE (LIKE ...) with foreign tables and views Composite types are not yet supported, because parserOpenTable() rejects them.
2012-01-10 20:46:29 +01:00
</para>
More minor updates and copy-editing.
2005-01-04 01:39:53 +01:00
</listitem>
</varlistentry>
Add FILLFACTOR to CREATE INDEX. ITAGAKI Takahiro
2006-07-02 04:23:23 +02:00
<varlistentry>
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
<term><literal>CONSTRAINT <replaceable class="parameter">constraint_name</replaceable></literal></term>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<listitem>
<para>
Add documentaiotn mention that constraint names can be sentences that can convey information to clients on constraint violation.
2006-01-16 20:50:03 +01:00
An optional name for a column or table constraint. If the
constraint is violated, the constraint name is present in error messages,
Improve constraint_name wording.
2006-01-16 21:48:49 +01:00
so constraint names like <literal>col must be positive</> can be used
Add markup for new constraint_name mention.
2006-01-16 20:53:12 +01:00
to communicate helpful constraint information to client applications.
Improve constraint_name wording.
2006-01-16 21:48:49 +01:00
(Double-quotes are needed to specify constraint names that contain spaces.)
If a constraint name is not specified, the system generates a name.
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
</para>
</listitem>
</varlistentry>
Complete merge of all old man page information. ecpg reference page still needs formatting.
1999-07-22 17:09:15 +02:00
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<varlistentry>
<term><literal>NOT NULL</></term>
<listitem>
<para>
More editing of reference pages.
2003-04-22 12:08:08 +02:00
The column is not allowed to contain null values.
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
</para>
</listitem>
</varlistentry>
Complete merge of all old man page information. ecpg reference page still needs formatting.
1999-07-22 17:09:15 +02:00
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<varlistentry>
<term><literal>NULL</></term>
<listitem>
<para>
More editing of reference pages.
2003-04-22 12:08:08 +02:00
The column is allowed to contain null values. This is the default.
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
</para>
Complete merge of all old man page information. ecpg reference page still needs formatting.
1999-07-22 17:09:15 +02:00
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<para>
More minor updates and copy-editing.
2005-01-04 01:39:53 +01:00
This clause is only provided for compatibility with
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
non-standard SQL databases. Its use is discouraged in new
applications.
</para>
</listitem>
</varlistentry>
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
Add exclusion constraints, which generalize the concept of uniqueness to support any indexable commutative operator, not just equality. Two rows violate the exclusion constraint if "row1.col OP row2.col" is TRUE for each of the columns in the constraint. Jeff Davis, reviewed by Robert Haas
2009-12-07 06:22:23 +01:00
<varlistentry>
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
<term><literal>CHECK ( <replaceable class="parameter">expression</replaceable> ) [ NO INHERIT ] </literal></term>
Add exclusion constraints, which generalize the concept of uniqueness to support any indexable commutative operator, not just equality. Two rows violate the exclusion constraint if "row1.col OP row2.col" is TRUE for each of the columns in the constraint. Jeff Davis, reviewed by Robert Haas
2009-12-07 06:22:23 +01:00
<listitem>
<para>
The <literal>CHECK</> clause specifies an expression producing a
Boolean result which new or updated rows must satisfy for an
insert or update operation to succeed. Expressions evaluating
to TRUE or UNKNOWN succeed. Should any row of an insert or
doc: add comma for clarity Patch by Etsuro Fujita
2015-03-20 21:58:19 +01:00
update operation produce a FALSE result, an error exception is
Add exclusion constraints, which generalize the concept of uniqueness to support any indexable commutative operator, not just equality. Two rows violate the exclusion constraint if "row1.col OP row2.col" is TRUE for each of the columns in the constraint. Jeff Davis, reviewed by Robert Haas
2009-12-07 06:22:23 +01:00
raised and the insert or update does not alter the database. A
check constraint specified as a column constraint should
reference that column's value only, while an expression
appearing in a table constraint can reference multiple columns.
</para>
<para>
Currently, <literal>CHECK</literal> expressions cannot contain
subqueries nor refer to variables other than columns of the
Don't allow system columns in CHECK constraints, except tableoid. Previously, arbitray system columns could be mentioned in table constraints, but they were not correctly checked at runtime, because the values weren't actually set correctly in the tuple. Since it seems easy enough to initialize the table OID properly, do that, and continue allowing that column, but disallow the rest unless and until someone figures out a way to make them work properly. No back-patch, because this doesn't seem important enough to take the risk of destabilizing the back branches. In fact, this will pose a dump-and-reload hazard for those upgrading from previous versions: constraints that were accepted before but were not correctly enforced will now either be enforced correctly or not accepted at all. Either could result in restore failures, but in practice I think very few users will notice the difference, since the use case is pretty marginal anyway and few users will be relying on features that have not historically worked. Amit Kapila, reviewed by Rushabh Lathia, with doc changes by me.
2013-09-23 19:31:22 +02:00
current row. The system column <literal>tableoid</literal>
may be referenced, but not any other system column.
Add exclusion constraints, which generalize the concept of uniqueness to support any indexable commutative operator, not just equality. Two rows violate the exclusion constraint if "row1.col OP row2.col" is TRUE for each of the columns in the constraint. Jeff Davis, reviewed by Robert Haas
2009-12-07 06:22:23 +01:00
</para>
Recast "ONLY" column CHECK constraints as NO INHERIT The original syntax wasn't universally loved, and it didn't allow its usage in CREATE TABLE, only ALTER TABLE. It now works everywhere, and it also allows using ALTER TABLE ONLY to add an uninherited CHECK constraint, per discussion. The pg_constraint column has accordingly been renamed connoinherit. This commit partly reverts some of the changes in 61d81bd28dbec65a6b144e0cd3d0bfe25913c3ac, particularly some pg_dump and psql bits, because now pg_get_constraintdef includes the necessary NO INHERIT within the constraint definition. Author: Nikhil Sontakke Some tweaks by me
2012-04-21 04:46:20 +02:00
<para>
A constraint marked with <literal>NO INHERIT</> will not propagate to
Minor improvements for CHECK NO INHERIT documentation. Fix typo spotted by Thom Brown, and improve wording in another area where Thom spotted a typo.
2012-04-24 03:59:17 +02:00
child tables.
Recast "ONLY" column CHECK constraints as NO INHERIT The original syntax wasn't universally loved, and it didn't allow its usage in CREATE TABLE, only ALTER TABLE. It now works everywhere, and it also allows using ALTER TABLE ONLY to add an uninherited CHECK constraint, per discussion. The pg_constraint column has accordingly been renamed connoinherit. This commit partly reverts some of the changes in 61d81bd28dbec65a6b144e0cd3d0bfe25913c3ac, particularly some pg_dump and psql bits, because now pg_get_constraintdef includes the necessary NO INHERIT within the constraint definition. Author: Nikhil Sontakke Some tweaks by me
2012-04-21 04:46:20 +02:00
</para>
Apply table and domain CHECK constraints in name order. Previously, CHECK constraints of the same scope were checked in whatever order they happened to be read from pg_constraint. (Usually, but not reliably, this would be creation order for domain constraints and reverse creation order for table constraints, because of differing implementation details.) Nondeterministic results of this sort are problematic at least for testing purposes, and in discussion it was agreed to be a violation of the principle of least astonishment. Therefore, borrow the principle already established for triggers, and apply such checks in name order (using strcmp() sort rules). This lets users control the check order if they have a mind to. Domain CHECK constraints still follow the rule of checking lower nested domains' constraints first; the name sort only applies to multiple constraints attached to the same domain. In passing, I failed to resist the temptation to wordsmith a bit in create_domain.sgml. Apply to HEAD only, since this could result in a behavioral change in existing applications, and the potential regression test failures have not actually been observed in our buildfarm.
2015-03-23 21:59:29 +01:00
<para>
When a table has multiple <literal>CHECK</literal> constraints,
they will be tested for each row in alphabetical order by name,
after checking <literal>NOT NULL</> constraints.
(<productname>PostgreSQL</> versions before 9.5 did not honor any
particular firing order for <literal>CHECK</literal> constraints.)
</para>
Add exclusion constraints, which generalize the concept of uniqueness to support any indexable commutative operator, not just equality. Two rows violate the exclusion constraint if "row1.col OP row2.col" is TRUE for each of the columns in the constraint. Jeff Davis, reviewed by Robert Haas
2009-12-07 06:22:23 +01:00
</listitem>
</varlistentry>
Reclassify DEFAULT as a column_constraint item in the CREATE TABLE syntax. This is how it was documented originally, but several years ago somebody decided that DEFAULT isn't a type of constraint. Well, the grammar thinks it is. The documentation was wrong in two ways: it alleged that DEFAULT had to appear before any other kind of constraint, and it alleged that you can't prefix a DEFAULT clause with a "CONSTRAINT name" clause, when in fact you can. (The latter behavior probably isn't SQL-standard, but our grammar has always allowed it.) This patch responds to Fujii Masao's observation that the ALTER TABLE documentation mistakenly implied that you couldn't include DEFAULT in ALTER TABLE ADD COLUMN; though this isn't the way he proposed fixing it.
2010-12-29 03:38:05 +01:00
<varlistentry>
<term><literal>DEFAULT
<replaceable>default_expr</replaceable></literal></term>
<listitem>
<para>
The <literal>DEFAULT</> clause assigns a default data value for
the column whose column definition it appears within. The value
is any variable-free expression (subqueries and cross-references
to other columns in the current table are not allowed). The
data type of the default expression must match the data type of the
column.
</para>
<para>
The default expression will be used in any insert operation that
does not specify a value for the column. If there is no default
for a column, then the default is null.
</para>
</listitem>
</varlistentry>
Identity columns This is the SQL standard-conforming variant of PostgreSQL's serial columns. It fixes a few usability issues that serial columns have: - CREATE TABLE / LIKE copies default but refers to same sequence - cannot add/drop serialness with ALTER TABLE - dropping default does not drop sequence - need to grant separate privileges to sequence - other slight weirdnesses because serial is some kind of special macro Reviewed-by: Vitaly Burovoy <vitaly.burovoy@gmail.com>
2017-04-06 14:33:16 +02:00
<varlistentry>
<term><literal>GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY [ ( <replaceable>sequence_options</replaceable> ) ]</literal></term>
<listitem>
<para>
This clause creates the column as an <firstterm>identity
column</firstterm>. It will have an implicit sequence attached to it
and the column in new rows will automatically have values from the
sequence assigned to it.
</para>
<para>
The clauses <literal>ALWAYS</literal> and <literal>BY DEFAULT</literal>
determine how the sequence value is given precedence over a
user-specified value in an <command>INSERT</command> statement.
If <literal>ALWAYS</literal> is specified, a user-specified value is
only accepted if the <command>INSERT</command> statement
specifies <literal>OVERRIDING SYSTEM VALUE</literal>. If <literal>BY
DEFAULT</literal> is specified, then the user-specified value takes
precedence. See <xref linkend="sql-insert"> for details. (In
the <command>COPY</command> command, user-specified values are always
used regardless of this setting.)
</para>
<para>
The optional <replaceable>sequence_options</replaceable> clause can be
used to override the options of the sequence.
See <xref linkend="sql-createsequence"> for details.
</para>
</listitem>
</varlistentry>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<varlistentry>
<term><literal>UNIQUE</> (column constraint)</term>
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
<term><literal>UNIQUE ( <replaceable class="parameter">column_name</replaceable> [, ... ] )</> (table constraint)</term>
Revert CREATE INDEX ... INCLUDING ... It's not ready yet, revert two commits 690c543550b0d2852060c18d270cdb534d339d9a - unstable test output 386e3d7609c49505e079c40c65919d99feb82505 - patch itself
2016-04-08 20:52:13 +02:00
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<listitem>
<para>
More editing of reference pages.
2003-04-22 12:08:08 +02:00
The <literal>UNIQUE</literal> constraint specifies that a
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
group of one or more columns of a table can contain
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
only unique values. The behavior of the unique table constraint
is the same as that for column constraints, with the additional
capability to span multiple columns.
</para>
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<para>
More editing of reference pages.
2003-04-22 12:08:08 +02:00
For the purpose of a unique constraint, null values are not
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
considered equal.
</para>
Editing and markup cleanup.
1998-09-22 17:48:03 +02:00
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<para>
Each unique table constraint must name a set of columns that is
different from the set of columns named by any other unique or
primary key constraint defined for the table. (Otherwise it
would just be the same constraint listed twice.)
</para>
</listitem>
</varlistentry>
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<varlistentry>
<term><literal>PRIMARY KEY</> (column constraint)</term>
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
<term><literal>PRIMARY KEY ( <replaceable class="parameter">column_name</replaceable> [, ... ] )</> (table constraint)</term>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<listitem>
<para>
Improve documentation about PRIMARY KEY constraints. Get rid of the false implication that PRIMARY KEY is exactly equivalent to UNIQUE + NOT NULL. That was more-or-less true at one time in our implementation, but the standard doesn't say that, and we've grown various features (many of them required by spec) that treat a pkey differently from less-formal constraints. Per recent discussion on pgsql-general. I failed to resist the temptation to do some other wordsmithing in the same area.
2016-02-07 22:02:44 +01:00
The <literal>PRIMARY KEY</> constraint specifies that a column or
columns of a table can contain only unique (non-duplicate), nonnull
values. Only one primary key can be specified for a table, whether as a
column constraint or a table constraint.
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
</para>
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<para>
Improve documentation about PRIMARY KEY constraints. Get rid of the false implication that PRIMARY KEY is exactly equivalent to UNIQUE + NOT NULL. That was more-or-less true at one time in our implementation, but the standard doesn't say that, and we've grown various features (many of them required by spec) that treat a pkey differently from less-formal constraints. Per recent discussion on pgsql-general. I failed to resist the temptation to do some other wordsmithing in the same area.
2016-02-07 22:02:44 +01:00
The primary key constraint should name a set of columns that is
different from the set of columns named by any unique
constraint defined for the same table. (Otherwise, the unique
constraint is redundant and will be discarded.)
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
</para>
Editing and markup cleanup.
1998-09-22 17:48:03 +02:00
Minor updates for release. Split reference pages for CREATE TABLE AS and SELECT INTO to allow psgml (the emacs parser) to handle parsing.
1999-06-14 09:37:05 +02:00
<para>
Improve documentation about PRIMARY KEY constraints. Get rid of the false implication that PRIMARY KEY is exactly equivalent to UNIQUE + NOT NULL. That was more-or-less true at one time in our implementation, but the standard doesn't say that, and we've grown various features (many of them required by spec) that treat a pkey differently from less-formal constraints. Per recent discussion on pgsql-general. I failed to resist the temptation to do some other wordsmithing in the same area.
2016-02-07 22:02:44 +01:00
<literal>PRIMARY KEY</literal> enforces the same data constraints as
a combination of <literal>UNIQUE</> and <literal>NOT NULL</>, but
identifying a set of columns as the primary key also provides metadata
about the design of the schema, since a primary key implies that other
tables can rely on this set of columns as a unique identifier for rows.
Minor updates for release. Split reference pages for CREATE TABLE AS and SELECT INTO to allow psgml (the emacs parser) to handle parsing.
1999-06-14 09:37:05 +02:00
</para>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
</listitem>
</varlistentry>
Editing and markup cleanup.
1998-09-22 17:48:03 +02:00
Improve 9.0 release notes by removing extra parentheses and linking to a more appropriate place for exclusion constraints.
2010-04-01 02:18:21 +02:00
<varlistentry id="SQL-CREATETABLE-EXCLUDE">
Add exclusion constraints, which generalize the concept of uniqueness to support any indexable commutative operator, not just equality. Two rows violate the exclusion constraint if "row1.col OP row2.col" is TRUE for each of the columns in the constraint. Jeff Davis, reviewed by Robert Haas
2009-12-07 06:22:23 +01:00
<term><literal>EXCLUDE [ USING <replaceable class="parameter">index_method</replaceable> ] ( <replaceable class="parameter">exclude_element</replaceable> WITH <replaceable class="parameter">operator</replaceable> [, ... ] ) <replaceable class="parameter">index_parameters</replaceable> [ WHERE ( <replaceable class="parameter">predicate</replaceable> ) ]</literal></term>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<listitem>
<para>
Add exclusion constraints, which generalize the concept of uniqueness to support any indexable commutative operator, not just equality. Two rows violate the exclusion constraint if "row1.col OP row2.col" is TRUE for each of the columns in the constraint. Jeff Davis, reviewed by Robert Haas
2009-12-07 06:22:23 +01:00
The <literal>EXCLUDE</> clause defines an exclusion
constraint, which guarantees that if
any two rows are compared on the specified column(s) or
expression(s) using the specified operator(s), not all of these
comparisons will return <literal>TRUE</>. If all of the
specified operators test for equality, this is equivalent to a
<literal>UNIQUE</> constraint, although an ordinary unique constraint
will be faster. However, exclusion constraints can specify
constraints that are more general than simple equality.
For example, you can specify a constraint that
no two rows in the table contain overlapping circles
(see <xref linkend="datatype-geometric">) by using the
Entity-ify a few new uses of literal <, >, and &.
2010-02-27 05:29:44 +01:00
<literal>&amp;&amp;</> operator.
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
</para>
Editing and markup cleanup.
1998-09-22 17:48:03 +02:00
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<para>
Add exclusion constraints, which generalize the concept of uniqueness to support any indexable commutative operator, not just equality. Two rows violate the exclusion constraint if "row1.col OP row2.col" is TRUE for each of the columns in the constraint. Jeff Davis, reviewed by Robert Haas
2009-12-07 06:22:23 +01:00
Exclusion constraints are implemented using
an index, so each specified operator must be associated with an
appropriate operator class
(see <xref linkend="indexes-opclass">) for the index access
method <replaceable>index_method</>.
The operators are required to be commutative.
Each <replaceable class="parameter">exclude_element</replaceable>
can optionally specify an operator class and/or ordering options;
these are described fully under
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02:00
<xref linkend="sql-createindex">.
Add exclusion constraints, which generalize the concept of uniqueness to support any indexable commutative operator, not just equality. Two rows violate the exclusion constraint if "row1.col OP row2.col" is TRUE for each of the columns in the constraint. Jeff Davis, reviewed by Robert Haas
2009-12-07 06:22:23 +01:00
</para>
<para>
The access method must support <literal>amgettuple</> (see <xref
linkend="indexam">); at present this means <acronym>GIN</>
cannot be used. Although it's allowed, there is little point in using
Spell and markup checking
2010-08-17 06:37:21 +02:00
B-tree or hash indexes with an exclusion constraint, because this
Add exclusion constraints, which generalize the concept of uniqueness to support any indexable commutative operator, not just equality. Two rows violate the exclusion constraint if "row1.col OP row2.col" is TRUE for each of the columns in the constraint. Jeff Davis, reviewed by Robert Haas
2009-12-07 06:22:23 +01:00
does nothing that an ordinary unique constraint doesn't do better.
Add SP-GiST (space-partitioned GiST) index access method. SP-GiST is comparable to GiST in flexibility, but supports non-balanced partitioned search structures rather than balanced trees. As described at PGCon 2011, this new indexing structure can beat GiST in both index build time and query speed for search problems that it is well matched to. There are a number of areas that could still use improvement, but at this point the code seems committable. Teodor Sigaev and Oleg Bartunov, with considerable revisions by Tom Lane
2011-12-17 22:41:16 +01:00
So in practice the access method will always be <acronym>GiST</> or
<acronym>SP-GiST</>.
Add exclusion constraints, which generalize the concept of uniqueness to support any indexable commutative operator, not just equality. Two rows violate the exclusion constraint if "row1.col OP row2.col" is TRUE for each of the columns in the constraint. Jeff Davis, reviewed by Robert Haas
2009-12-07 06:22:23 +01:00
</para>
<para>
The <replaceable class="parameter">predicate</> allows you to specify an
exclusion constraint on a subset of the table; internally this creates a
partial index. Note that parentheses are required around the predicate.
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
</para>
</listitem>
</varlistentry>
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<varlistentry>
<term><literal>REFERENCES <replaceable class="parameter">reftable</replaceable> [ ( <replaceable class="parameter">refcolumn</replaceable> ) ] [ MATCH <replaceable class="parameter">matchtype</replaceable> ] [ ON DELETE <replaceable class="parameter">action</replaceable> ] [ ON UPDATE <replaceable class="parameter">action</replaceable> ]</literal> (column constraint)</term>
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
Make placeholders in SQL command help more consistent and precise To avoid divergent names on related pages, avoid ambiguities, and reduce translation work a little.
2012-06-22 00:06:14 +02:00
<term><literal>FOREIGN KEY ( <replaceable class="parameter">column_name</replaceable> [, ... ] )
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
REFERENCES <replaceable class="parameter">reftable</replaceable> [ ( <replaceable class="parameter">refcolumn</replaceable> [, ... ] ) ]
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
[ MATCH <replaceable class="parameter">matchtype</replaceable> ]
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
[ ON DELETE <replaceable class="parameter">action</replaceable> ]
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
[ ON UPDATE <replaceable class="parameter">action</replaceable> ]</literal>
(table constraint)</term>
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<listitem>
<para>
Disallow referential integrity actions from being deferred; only the NO ACTION check is deferrable. This seems to be a closer approximation to what the SQL spec says than what we were doing before, and it prevents some anomalous behaviors that are possible now that triggers can fire during the execution of PL functions. Stephan Szabo.
2004-10-21 23:33:59 +02:00
These clauses specify a foreign key constraint, which requires
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
that a group of one or more columns of the new table must only
Disallow referential integrity actions from being deferred; only the NO ACTION check is deferrable. This seems to be a closer approximation to what the SQL spec says than what we were doing before, and it prevents some anomalous behaviors that are possible now that triggers can fire during the execution of PL functions. Stephan Szabo.
2004-10-21 23:33:59 +02:00
contain values that match values in the referenced
Change ON UPDATE SET NULL/SET DEFAULT referential actions to meet SQL spec. Previously, when executing an ON UPDATE SET NULL or SET DEFAULT action for a multicolumn MATCH SIMPLE foreign key constraint, we would set only those referencing columns corresponding to referenced columns that were changed. This is what the SQL92 standard said to do --- but more recent versions of the standard say that all referencing columns should be set to null or their default values, no matter exactly which referenced columns changed. At least for SET DEFAULT, that is clearly saner behavior. It's somewhat debatable whether it's an improvement for SET NULL, but it appears that other RDBMS systems read the spec this way. So let's do it like that. This is a release-notable behavioral change, although considering that our documentation already implied it was done this way, the lack of complaints suggests few people use such cases.
2012-06-18 18:12:52 +02:00
column(s) of some row of the referenced table. If the <replaceable
class="parameter">refcolumn</replaceable> list is omitted, the
Support deferrable uniqueness constraints. The current implementation fires an AFTER ROW trigger for each tuple that looks like it might be non-unique according to the index contents at the time of insertion. This works well as long as there aren't many conflicts, but won't scale to massive unique-key reassignments. Improving that case is a TODO item. Dean Rasheed
2009-07-29 22:56:21 +02:00
primary key of the <replaceable class="parameter">reftable</replaceable>
is used. The referenced columns must be the columns of a non-deferrable
For foreign keys, check REFERENCES privilege only on the referenced table. We were requiring that the user have REFERENCES permission on both the referenced and referencing tables --- but this doesn't seem to have any support in the SQL standard, which says only that you need REFERENCES permission on the referenced table. And ALTER TABLE ADD FOREIGN KEY has already checked that you own the referencing table, so the check could only fail if a table owner has revoked his own REFERENCES permission. Moreover, the symmetric interpretation of this permission is unintuitive and confusing, as per complaint from Paul Jungwirth. So let's drop the referencing-side check. In passing, do a bit of wordsmithing on the GRANT reference page so that all the privilege types are described in similar fashion. Discussion: https://postgr.es/m/8940.1490906755@sss.pgh.pa.us
2017-04-01 00:11:25 +02:00
unique or primary key constraint in the referenced table. The user
must have <literal>REFERENCES</> permission on the referenced table
(either the whole table, or the specific referenced columns).
Note that foreign key constraints cannot be defined between temporary
tables and permanent tables.
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
</para>
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<para>
Disallow referential integrity actions from being deferred; only the NO ACTION check is deferrable. This seems to be a closer approximation to what the SQL spec says than what we were doing before, and it prevents some anomalous behaviors that are possible now that triggers can fire during the execution of PL functions. Stephan Szabo.
2004-10-21 23:33:59 +02:00
A value inserted into the referencing column(s) is matched against the
More editing of reference pages.
2003-04-22 12:08:08 +02:00
values of the referenced table and referenced columns using the
given match type. There are three match types: <literal>MATCH
FULL</>, <literal>MATCH PARTIAL</>, and <literal>MATCH
Change ON UPDATE SET NULL/SET DEFAULT referential actions to meet SQL spec. Previously, when executing an ON UPDATE SET NULL or SET DEFAULT action for a multicolumn MATCH SIMPLE foreign key constraint, we would set only those referencing columns corresponding to referenced columns that were changed. This is what the SQL92 standard said to do --- but more recent versions of the standard say that all referencing columns should be set to null or their default values, no matter exactly which referenced columns changed. At least for SET DEFAULT, that is clearly saner behavior. It's somewhat debatable whether it's an improvement for SET NULL, but it appears that other RDBMS systems read the spec this way. So let's do it like that. This is a release-notable behavioral change, although considering that our documentation already implied it was done this way, the lack of complaints suggests few people use such cases.
2012-06-18 18:12:52 +02:00
SIMPLE</literal> (which is the default). <literal>MATCH
More editing of reference pages.
2003-04-22 12:08:08 +02:00
FULL</> will not allow one column of a multicolumn foreign key
Change ON UPDATE SET NULL/SET DEFAULT referential actions to meet SQL spec. Previously, when executing an ON UPDATE SET NULL or SET DEFAULT action for a multicolumn MATCH SIMPLE foreign key constraint, we would set only those referencing columns corresponding to referenced columns that were changed. This is what the SQL92 standard said to do --- but more recent versions of the standard say that all referencing columns should be set to null or their default values, no matter exactly which referenced columns changed. At least for SET DEFAULT, that is clearly saner behavior. It's somewhat debatable whether it's an improvement for SET NULL, but it appears that other RDBMS systems read the spec this way. So let's do it like that. This is a release-notable behavioral change, although considering that our documentation already implied it was done this way, the lack of complaints suggests few people use such cases.
2012-06-18 18:12:52 +02:00
to be null unless all foreign key columns are null; if they are all
null, the row is not required to have a match in the referenced table.
<literal>MATCH SIMPLE</literal> allows any of the foreign key columns
to be null; if any of them are null, the row is not required to have a
match in the referenced table.
<literal>MATCH PARTIAL</> is not yet implemented.
(Of course, <literal>NOT NULL</> constraints can be applied to the
referencing column(s) to prevent these cases from arising.)
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
</para>
Attached is are diffs for CREATE/ALTER table doc I've forgotten in my mailbox (sorry). Haven't tried to apply and since I don't have working sgml stuff cannot check. Jan
2000-04-11 16:43:54 +02:00
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<para>
In addition, when the data in the referenced columns is changed,
certain actions are performed on the data in this table's
columns. The <literal>ON DELETE</literal> clause specifies the
More editing of reference pages.
2003-04-22 12:08:08 +02:00
action to perform when a referenced row in the referenced table is
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
being deleted. Likewise, the <literal>ON UPDATE</literal>
clause specifies the action to perform when a referenced column
in the referenced table is being updated to a new value. If the
row is updated, but the referenced column is not actually
More minor updates and copy-editing.
2005-01-04 01:39:53 +01:00
changed, no action is done. Referential actions other than the
<literal>NO ACTION</literal> check cannot be deferred, even if
the constraint is declared deferrable. There are the following possible
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
actions for each clause:
<variablelist>
<varlistentry>
<term><literal>NO ACTION</literal></term>
<listitem>
<para>
Produce an error indicating that the deletion or update
Disallow referential integrity actions from being deferred; only the NO ACTION check is deferrable. This seems to be a closer approximation to what the SQL spec says than what we were doing before, and it prevents some anomalous behaviors that are possible now that triggers can fire during the execution of PL functions. Stephan Szabo.
2004-10-21 23:33:59 +02:00
would create a foreign key constraint violation.
If the constraint is deferred, this
error will be produced at constraint check time if there still
exist any referencing rows. This is the default action.
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>RESTRICT</literal></term>
<listitem>
<para>
Disallow referential integrity actions from being deferred; only the NO ACTION check is deferrable. This seems to be a closer approximation to what the SQL spec says than what we were doing before, and it prevents some anomalous behaviors that are possible now that triggers can fire during the execution of PL functions. Stephan Szabo.
2004-10-21 23:33:59 +02:00
Produce an error indicating that the deletion or update
would create a foreign key constraint violation.
This is the same as <literal>NO ACTION</literal> except that
More minor updates and copy-editing.
2005-01-04 01:39:53 +01:00
the check is not deferrable.
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>CASCADE</literal></term>
<listitem>
<para>
Delete any rows referencing the deleted row, or update the
Change ON UPDATE SET NULL/SET DEFAULT referential actions to meet SQL spec. Previously, when executing an ON UPDATE SET NULL or SET DEFAULT action for a multicolumn MATCH SIMPLE foreign key constraint, we would set only those referencing columns corresponding to referenced columns that were changed. This is what the SQL92 standard said to do --- but more recent versions of the standard say that all referencing columns should be set to null or their default values, no matter exactly which referenced columns changed. At least for SET DEFAULT, that is clearly saner behavior. It's somewhat debatable whether it's an improvement for SET NULL, but it appears that other RDBMS systems read the spec this way. So let's do it like that. This is a release-notable behavioral change, although considering that our documentation already implied it was done this way, the lack of complaints suggests few people use such cases.
2012-06-18 18:12:52 +02:00
values of the referencing column(s) to the new values of the
referenced columns, respectively.
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>SET NULL</literal></term>
<listitem>
<para>
Disallow referential integrity actions from being deferred; only the NO ACTION check is deferrable. This seems to be a closer approximation to what the SQL spec says than what we were doing before, and it prevents some anomalous behaviors that are possible now that triggers can fire during the execution of PL functions. Stephan Szabo.
2004-10-21 23:33:59 +02:00
Set the referencing column(s) to null.
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>SET DEFAULT</literal></term>
<listitem>
<para>
Disallow referential integrity actions from being deferred; only the NO ACTION check is deferrable. This seems to be a closer approximation to what the SQL spec says than what we were doing before, and it prevents some anomalous behaviors that are possible now that triggers can fire during the execution of PL functions. Stephan Szabo.
2004-10-21 23:33:59 +02:00
Set the referencing column(s) to their default values.
Change ON UPDATE SET NULL/SET DEFAULT referential actions to meet SQL spec. Previously, when executing an ON UPDATE SET NULL or SET DEFAULT action for a multicolumn MATCH SIMPLE foreign key constraint, we would set only those referencing columns corresponding to referenced columns that were changed. This is what the SQL92 standard said to do --- but more recent versions of the standard say that all referencing columns should be set to null or their default values, no matter exactly which referenced columns changed. At least for SET DEFAULT, that is clearly saner behavior. It's somewhat debatable whether it's an improvement for SET NULL, but it appears that other RDBMS systems read the spec this way. So let's do it like that. This is a release-notable behavioral change, although considering that our documentation already implied it was done this way, the lack of complaints suggests few people use such cases.
2012-06-18 18:12:52 +02:00
(There must be a row in the referenced table matching the default
values, if they are not null, or the operation will fail.)
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
</para>
</listitem>
</varlistentry>
</variablelist>
</para>
More editing of reference pages.
2003-04-22 12:08:08 +02:00
Add mention of index on foreign key for frequently updated primary key tables.
2002-01-03 07:26:22 +01:00
<para>
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
If the referenced column(s) are changed frequently, it might be wise to
Change ON UPDATE SET NULL/SET DEFAULT referential actions to meet SQL spec. Previously, when executing an ON UPDATE SET NULL or SET DEFAULT action for a multicolumn MATCH SIMPLE foreign key constraint, we would set only those referencing columns corresponding to referenced columns that were changed. This is what the SQL92 standard said to do --- but more recent versions of the standard say that all referencing columns should be set to null or their default values, no matter exactly which referenced columns changed. At least for SET DEFAULT, that is clearly saner behavior. It's somewhat debatable whether it's an improvement for SET NULL, but it appears that other RDBMS systems read the spec this way. So let's do it like that. This is a release-notable behavioral change, although considering that our documentation already implied it was done this way, the lack of complaints suggests few people use such cases.
2012-06-18 18:12:52 +02:00
add an index to the referencing column(s) so that referential actions
associated with the foreign key constraint can be performed more
Disallow referential integrity actions from being deferred; only the NO ACTION check is deferrable. This seems to be a closer approximation to what the SQL spec says than what we were doing before, and it prevents some anomalous behaviors that are possible now that triggers can fire during the execution of PL functions. Stephan Szabo.
2004-10-21 23:33:59 +02:00
efficiently.
Add mention of index on foreign key for frequently updated primary key tables.
2002-01-03 07:26:22 +01:00
</para>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
</listitem>
</varlistentry>
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<varlistentry>
More editing of reference pages.
2003-04-22 12:08:08 +02:00
<term><literal>DEFERRABLE</literal></term>
<term><literal>NOT DEFERRABLE</literal></term>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<listitem>
<para>
This controls whether the constraint can be deferred. A
constraint that is not deferrable will be checked immediately
after every command. Checking of constraints that are
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
deferrable can be postponed until the end of the transaction
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02:00
(using the <xref linkend="sql-set-constraints"> command).
Support deferrable uniqueness constraints. The current implementation fires an AFTER ROW trigger for each tuple that looks like it might be non-unique according to the index contents at the time of insertion. This works well as long as there aren't many conflicts, but won't scale to massive unique-key reassignments. Improving that case is a TODO item. Dean Rasheed
2009-07-29 22:56:21 +02:00
<literal>NOT DEFERRABLE</literal> is the default.
Add exclusion constraints, which generalize the concept of uniqueness to support any indexable commutative operator, not just equality. Two rows violate the exclusion constraint if "row1.col OP row2.col" is TRUE for each of the columns in the constraint. Jeff Davis, reviewed by Robert Haas
2009-12-07 06:22:23 +01:00
Currently, only <literal>UNIQUE</>, <literal>PRIMARY KEY</>,
<literal>EXCLUDE</>, and
Support deferrable uniqueness constraints. The current implementation fires an AFTER ROW trigger for each tuple that looks like it might be non-unique according to the index contents at the time of insertion. This works well as long as there aren't many conflicts, but won't scale to massive unique-key reassignments. Improving that case is a TODO item. Dean Rasheed
2009-07-29 22:56:21 +02:00
<literal>REFERENCES</> (foreign key) constraints accept this
clause. <literal>NOT NULL</> and <literal>CHECK</> constraints are not
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE. The newly added ON CONFLICT clause allows to specify an alternative to raising a unique or exclusion constraint violation error when inserting. ON CONFLICT refers to constraints that can either be specified using a inference clause (by specifying the columns of a unique constraint) or by naming a unique or exclusion constraint. DO NOTHING avoids the constraint violation, without touching the pre-existing row. DO UPDATE SET ... [WHERE ...] updates the pre-existing tuple, and has access to both the tuple proposed for insertion and the existing tuple; the optional WHERE clause can be used to prevent an update from being executed. The UPDATE SET and WHERE clauses have access to the tuple proposed for insertion using the "magic" EXCLUDED alias, and to the pre-existing tuple using the table name or its alias. This feature is often referred to as upsert. This is implemented using a new infrastructure called "speculative insertion". It is an optimistic variant of regular insertion that first does a pre-check for existing tuples and then attempts an insert. If a violating tuple was inserted concurrently, the speculatively inserted tuple is deleted and a new attempt is made. If the pre-check finds a matching tuple the alternative DO NOTHING or DO UPDATE action is taken. If the insertion succeeds without detecting a conflict, the tuple is deemed inserted. To handle the possible ambiguity between the excluded alias and a table named excluded, and for convenience with long relation names, INSERT INTO now can alias its target table. Bumps catversion as stored rules change. Author: Peter Geoghegan, with significant contributions from Heikki Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes. Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs, Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
deferrable. Note that deferrable constraints cannot be used as
conflict arbitrators in an <command>INSERT</command> statement that
includes an <literal>ON CONFLICT DO UPDATE</> clause.
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
</para>
</listitem>
</varlistentry>
Attached is are diffs for CREATE/ALTER table doc I've forgotten in my mailbox (sorry). Haven't tried to apply and since I don't have working sgml stuff cannot check. Jan
2000-04-11 16:43:54 +02:00
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<varlistentry>
More editing of reference pages.
2003-04-22 12:08:08 +02:00
<term><literal>INITIALLY IMMEDIATE</literal></term>
<term><literal>INITIALLY DEFERRED</literal></term>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<listitem>
<para>
If a constraint is deferrable, this clause specifies the default
time to check the constraint. If the constraint is
<literal>INITIALLY IMMEDIATE</literal>, it is checked after each
statement. This is the default. If the constraint is
<literal>INITIALLY DEFERRED</literal>, it is checked only at the
end of the transaction. The constraint check time can be
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02:00
altered with the <xref linkend="sql-set-constraints"> command.
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
</para>
</listitem>
</varlistentry>
Add mention of index on foreign key for frequently updated primary key tables.
2002-01-03 07:26:22 +01:00
Documentation fixes for FILLFACTOR patch. Minor other editorialization.
2006-07-04 20:07:24 +02:00
<varlistentry>
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
<term><literal>WITH ( <replaceable class="parameter">storage_parameter</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] )</literal></term>
Documentation fixes for FILLFACTOR patch. Minor other editorialization.
2006-07-04 20:07:24 +02:00
<listitem>
<para>
This clause specifies optional storage parameters for a table or index;
see <xref linkend="sql-createtable-storage-parameters"
endterm="sql-createtable-storage-parameters-title"> for more
information. The <literal>WITH</> clause for a
table can also include <literal>OIDS=TRUE</> (or just <literal>OIDS</>)
to specify that rows of the new table
should have OIDs (object identifiers) assigned to them, or
<literal>OIDS=FALSE</> to specify that the rows should not have OIDs.
If <literal>OIDS</> is not specified, the default setting depends upon
the <xref linkend="guc-default-with-oids"> configuration parameter.
(If the new table inherits from any tables that have OIDs, then
<literal>OIDS=TRUE</> is forced even if the command says
<literal>OIDS=FALSE</>.)
</para>
<para>
If <literal>OIDS=FALSE</literal> is specified or implied, the new
table does not store OIDs and no OID will be assigned for a row inserted
into it. This is generally considered worthwhile, since it
will reduce OID consumption and thereby postpone the wraparound
of the 32-bit OID counter. Once the counter wraps around, OIDs
can no longer be assumed to be unique, which makes them
considerably less useful. In addition, excluding OIDs from a
table reduces the space required to store the table on disk by
4 bytes per row (on most machines), slightly improving performance.
</para>
<para>
To remove OIDs from a table after it has been created, use <xref
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02:00
linkend="sql-altertable">.
Documentation fixes for FILLFACTOR patch. Minor other editorialization.
2006-07-04 20:07:24 +02:00
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>WITH OIDS</></term>
<term><literal>WITHOUT OIDS</></term>
<listitem>
<para>
These are obsolescent syntaxes equivalent to <literal>WITH (OIDS)</>
and <literal>WITH (OIDS=FALSE)</>, respectively. If you wish to give
both an <literal>OIDS</> setting and storage parameters, you must use
the <literal>WITH ( ... )</> syntax; see above.
</para>
</listitem>
</varlistentry>
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
<varlistentry>
<term><literal>ON COMMIT</literal></term>
<listitem>
<para>
Code review for ON COMMIT patch. Make the actual on-commit action happen before commit, not after :-( --- the original coding is not only unsafe if an error occurs while it's processing, but it generates an invalid sequence of WAL entries. Resurrect 7.2 logic for deleting items when no longer needed. Use an enum instead of random macros. Editorialize on names used for routines and constants. Teach backend/nodes routines about new field in CreateTable struct. Add a regression test.
2002-11-11 23:19:25 +01:00
The behavior of temporary tables at the end of a transaction
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
block can be controlled using <literal>ON COMMIT</literal>.
Code review for ON COMMIT patch. Make the actual on-commit action happen before commit, not after :-( --- the original coding is not only unsafe if an error occurs while it's processing, but it generates an invalid sequence of WAL entries. Resurrect 7.2 logic for deleting items when no longer needed. Use an enum instead of random macros. Editorialize on names used for routines and constants. Teach backend/nodes routines about new field in CreateTable struct. Add a regression test.
2002-11-11 23:19:25 +01:00
The three options are:
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
<variablelist>
<varlistentry>
<term><literal>PRESERVE ROWS</literal></term>
<listitem>
<para>
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
No special action is taken at the ends of transactions.
This is the default behavior.
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
</para>
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
</listitem>
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
</varlistentry>
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
<varlistentry>
<term><literal>DELETE ROWS</literal></term>
<listitem>
<para>
Add TABLESPACE and ON COMMIT clauses to CREATE TABLE AS. ON COMMIT is required by the SQL standard, and TABLESPACE is useful functionality. Patch from Kris Jurka, minor editorialization by Neil Conway.
2006-02-19 01:04:28 +01:00
All rows in the temporary table will be deleted at the end
of each transaction block. Essentially, an automatic <xref
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02:00
linkend="sql-truncate"> is done
Add TABLESPACE and ON COMMIT clauses to CREATE TABLE AS. ON COMMIT is required by the SQL standard, and TABLESPACE is useful functionality. Patch from Kris Jurka, minor editorialization by Neil Conway.
2006-02-19 01:04:28 +01:00
at each commit.
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
</para>
</listitem>
</varlistentry>
Add mention of index on foreign key for frequently updated primary key tables.
2002-01-03 07:26:22 +01:00
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
<varlistentry>
<term><literal>DROP</literal></term>
<listitem>
<para>
Code review for ON COMMIT patch. Make the actual on-commit action happen before commit, not after :-( --- the original coding is not only unsafe if an error occurs while it's processing, but it generates an invalid sequence of WAL entries. Resurrect 7.2 logic for deleting items when no longer needed. Use an enum instead of random macros. Editorialize on names used for routines and constants. Teach backend/nodes routines about new field in CreateTable struct. Add a regression test.
2002-11-11 23:19:25 +01:00
The temporary table will be dropped at the end of the current
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
transaction block.
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
</para>
</listitem>
</varlistentry>
Fix a whitespace issue with the man pages There is what may actually be a mistake in our markup. The problem is in a situation like <para> <command>FOO</command> is ... there is strictly speaking a line break before "FOO". In the HTML output, this does not appear to be a problem, but in the man page output, this shows up, so you get double blank lines at odd places. So far, we have attempted to work around this with an XSL hack, but that causes other problems, such as creating run-ins in places like <acronym>SQL</acronym> <command>COPY</command> So fix the problem properly by removing the extra whitespace. I only fixed the problems that affect the man page output, not all the places.
2011-08-07 09:49:45 +02:00
</variablelist></para>
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
</listitem>
</varlistentry>
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
<varlistentry>
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
<term><literal>TABLESPACE <replaceable class="parameter">tablespace_name</replaceable></literal></term>
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
<listitem>
<para>
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
The <replaceable class="parameter">tablespace_name</replaceable> is the name
Create 'default_tablespace' GUC variable that supplies a TABLESPACE clause implicitly whenever one is not given explicitly. Remove concept of a schema having an associated tablespace, and simplify the rules for selecting a default tablespace for a table or index. It's now just (a) explicit TABLESPACE clause; (b) default_tablespace if that's not an empty string; (c) database's default. This will allow pg_dump to use SET commands instead of tablespace clauses to determine object locations (but I didn't actually make it do so). All per recent discussions.
2004-11-05 20:17:13 +01:00
of the tablespace in which the new table is to be created.
If not specified,
Create a GUC parameter temp_tablespaces that allows selection of the tablespace(s) in which to store temp tables and temporary files. This is a list to allow spreading the load across multiple tablespaces (a random list element is chosen each time a temp object is to be created). Temp files are not stored in per-database pgsql_tmp/ directories anymore, but per-tablespace directories. Jaime Casanova and Albert Cervera, with review by Bernd Helmle and Tom Lane.
2007-06-03 19:08:34 +02:00
<xref linkend="guc-default-tablespace"> is consulted, or
<xref linkend="guc-temp-tablespaces"> if the table is temporary.
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
</para>
</listitem>
</varlistentry>
Support USING INDEX TABLESPACE clause for PRIMARY KEY and UNIQUE constraints. Christopher Kings-Lynne.
2004-08-02 06:28:29 +02:00
<varlistentry>
Use lower-case SGML attribute values for DocBook XML compatibility
2017-10-09 04:00:57 +02:00
<term><literal>USING INDEX TABLESPACE <replaceable class="parameter">tablespace_name</replaceable></literal></term>
Support USING INDEX TABLESPACE clause for PRIMARY KEY and UNIQUE constraints. Christopher Kings-Lynne.
2004-08-02 06:28:29 +02:00
<listitem>
<para>
This clause allows selection of the tablespace in which the index
Add exclusion constraints, which generalize the concept of uniqueness to support any indexable commutative operator, not just equality. Two rows violate the exclusion constraint if "row1.col OP row2.col" is TRUE for each of the columns in the constraint. Jeff Davis, reviewed by Robert Haas
2009-12-07 06:22:23 +01:00
associated with a <literal>UNIQUE</literal>, <literal>PRIMARY
KEY</literal>, or <literal>EXCLUDE</> constraint will be created.
Create 'default_tablespace' GUC variable that supplies a TABLESPACE clause implicitly whenever one is not given explicitly. Remove concept of a schema having an associated tablespace, and simplify the rules for selecting a default tablespace for a table or index. It's now just (a) explicit TABLESPACE clause; (b) default_tablespace if that's not an empty string; (c) database's default. This will allow pg_dump to use SET commands instead of tablespace clauses to determine object locations (but I didn't actually make it do so). All per recent discussions.
2004-11-05 20:17:13 +01:00
If not specified,
Create a GUC parameter temp_tablespaces that allows selection of the tablespace(s) in which to store temp tables and temporary files. This is a list to allow spreading the load across multiple tablespaces (a random list element is chosen each time a temp object is to be created). Temp files are not stored in per-database pgsql_tmp/ directories anymore, but per-tablespace directories. Jaime Casanova and Albert Cervera, with review by Bernd Helmle and Tom Lane.
2007-06-03 19:08:34 +02:00
<xref linkend="guc-default-tablespace"> is consulted, or
<xref linkend="guc-temp-tablespaces"> if the table is temporary.
Support USING INDEX TABLESPACE clause for PRIMARY KEY and UNIQUE constraints. Christopher Kings-Lynne.
2004-08-02 06:28:29 +02:00
</para>
</listitem>
</varlistentry>
Add code to handle [ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP }] for temp tables. Gavin Sherry
2002-11-10 00:56:39 +01:00
</variablelist>
Documentation fixes for FILLFACTOR patch. Minor other editorialization.
2006-07-04 20:07:24 +02:00
<refsect2 id="SQL-CREATETABLE-storage-parameters">
<title id="SQL-CREATETABLE-storage-parameters-title">Storage Parameters</title>
Update autovacuum to use reloptions instead of a system catalog, for per-table overrides of parameters. This removes a whole class of problems related to misusing the catalog, and perhaps more importantly, gives us pg_dump support for the parameters. Based on a patch by Euler Taveira de Oliveira, heavily reworked by me.
2009-02-09 21:57:59 +01:00
<indexterm zone="sql-createtable-storage-parameters">
<primary>storage parameters</primary>
</indexterm>
Documentation fixes for FILLFACTOR patch. Minor other editorialization.
2006-07-04 20:07:24 +02:00
<para>
The <literal>WITH</> clause can specify <firstterm>storage parameters</>
Add exclusion constraints, which generalize the concept of uniqueness to support any indexable commutative operator, not just equality. Two rows violate the exclusion constraint if "row1.col OP row2.col" is TRUE for each of the columns in the constraint. Jeff Davis, reviewed by Robert Haas
2009-12-07 06:22:23 +01:00
for tables, and for indexes associated with a <literal>UNIQUE</literal>,
<literal>PRIMARY KEY</literal>, or <literal>EXCLUDE</> constraint.
Storage parameters for
Use "TOAST table" in place of the vague, not-used-elsewhere phrase "supplementary storage table".
2010-05-13 20:54:18 +02:00
indexes are documented in <xref linkend="SQL-CREATEINDEX">.
The storage parameters currently
Improve documentation around autovacuum-related storage parameters. These were discussed in three different sections of the manual, which unsurprisingly had diverged over time; and the descriptions of individual variables lacked stylistic consistency even within each section (and frequently weren't in very good English anyway). Clean up the mess, and remove some of the redundant information in hopes that future additions will be less likely to re-introduce inconsistency. For instance I see no need for maintenance.sgml to include its very own list of all the autovacuum storage parameters, especially since that list was already incomplete.
2015-11-11 23:13:38 +01:00
available for tables are listed below. For many of these parameters, as
shown, there is an additional parameter with the same name prefixed with
<literal>toast.</literal>, which controls the behavior of the
Use "TOAST table" in place of the vague, not-used-elsewhere phrase "supplementary storage table".
2010-05-13 20:54:18 +02:00
table's secondary <acronym>TOAST</> table, if any
(see <xref linkend="storage-toast"> for more information about TOAST).
Improve documentation around autovacuum-related storage parameters. These were discussed in three different sections of the manual, which unsurprisingly had diverged over time; and the descriptions of individual variables lacked stylistic consistency even within each section (and frequently weren't in very good English anyway). Clean up the mess, and remove some of the redundant information in hopes that future additions will be less likely to re-introduce inconsistency. For instance I see no need for maintenance.sgml to include its very own list of all the autovacuum storage parameters, especially since that list was already incomplete.
2015-11-11 23:13:38 +01:00
If a table parameter value is set and the
equivalent <literal>toast.</literal> parameter is not, the TOAST table
will use the table's parameter value.
Don't allocate storage for partitioned tables. Also, don't allow setting reloptions on them, since that would have no effect given the lack of storage. The patch does this by introducing a new reloption kind for which there are currently no reloptions -- we might have some in the future -- so it adjusts parseRelOptions to handle that case correctly. Bumped catversion. System catalogs that contained reloptions for partitioned tables are no longer valid; plus, there are now fewer physical files on disk, which is not technically a catalog change but still a good reason to re-initdb. Amit Langote, reviewed by Maksim Milyutin and Kyotaro Horiguchi and revised a bit by me. Discussion: http://postgr.es/m/20170331.173326.212311140.horiguchi.kyotaro@lab.ntt.co.jp
2017-03-31 22:28:30 +02:00
Specifying these parameters for partitioned tables is not supported,
but you may specify them for individual leaf partitions.
Documentation fixes for FILLFACTOR patch. Minor other editorialization.
2006-07-04 20:07:24 +02:00
</para>
<variablelist>
<varlistentry>
Fix documentation on the toast.fillfactor reloption: it doesn't exist. Per note from Zoltan Boszormenyi.
2009-10-27 14:58:28 +01:00
<term><literal>fillfactor</> (<type>integer</>)</term>
Documentation fixes for FILLFACTOR patch. Minor other editorialization.
2006-07-04 20:07:24 +02:00
<listitem>
<para>
The fillfactor for a table is a percentage between 10 and 100.
100 (complete packing) is the default. When a smaller fillfactor
is specified, <command>INSERT</> operations pack table pages only
to the indicated percentage; the remaining space on each page is
reserved for updating rows on that page. This gives <command>UPDATE</>
a chance to place the updated copy of a row on the same page as the
original, which is more efficient than placing it on a different page.
For a table whose entries are never updated, complete packing is the
best choice, but in heavily updated tables smaller fillfactors are
Use "TOAST table" in place of the vague, not-used-elsewhere phrase "supplementary storage table".
2010-05-13 20:54:18 +02:00
appropriate. This parameter cannot be set for TOAST tables.
Documentation fixes for FILLFACTOR patch. Minor other editorialization.
2006-07-04 20:07:24 +02:00
</para>
</listitem>
Allow reloption names to have qualifiers, initially supporting a TOAST qualifier, and add support for this in pg_dump. This allows TOAST tables to have user-defined fillfactor, and will also enable us to move the autovacuum parameters to reloptions without taking away the possibility of setting values for TOAST tables.
2009-02-02 20:31:40 +01:00
</varlistentry>
Add a 'parallel_degree' reloption. The code that estimates what parallel degree should be uesd for the scan of a relation is currently rather stupid, so add a parallel_degree reloption that can be used to override the planner's rather limited judgement. Julien Rouhaud, reviewed by David Rowley, James Sewell, Amit Kapila, and me. Some further hacking by me.
2016-04-08 17:14:56 +02:00
<varlistentry>
Eliminate "parallel degree" terminology. This terminology provoked widespread complaints. So, instead, rename the GUC max_parallel_degree to max_parallel_workers_per_gather (leaving room for a possible future GUC max_parallel_workers that acts as a system-wide limit), and rename the parallel_degree reloption to parallel_workers. Rename structure members to match. These changes create a dump/restore hazard for users of PostgreSQL 9.6beta1 who have set the reloption (or applied the GUC using ALTER USER or ALTER DATABASE).
2016-06-09 15:08:27 +02:00
<term><literal>parallel_workers</> (<type>integer</>)</term>
Add a 'parallel_degree' reloption. The code that estimates what parallel degree should be uesd for the scan of a relation is currently rather stupid, so add a parallel_degree reloption that can be used to override the planner's rather limited judgement. Julien Rouhaud, reviewed by David Rowley, James Sewell, Amit Kapila, and me. Some further hacking by me.
2016-04-08 17:14:56 +02:00
<listitem>
<para>
Eliminate "parallel degree" terminology. This terminology provoked widespread complaints. So, instead, rename the GUC max_parallel_degree to max_parallel_workers_per_gather (leaving room for a possible future GUC max_parallel_workers that acts as a system-wide limit), and rename the parallel_degree reloption to parallel_workers. Rename structure members to match. These changes create a dump/restore hazard for users of PostgreSQL 9.6beta1 who have set the reloption (or applied the GUC using ALTER USER or ALTER DATABASE).
2016-06-09 15:08:27 +02:00
This sets the number of workers that should be used to assist a parallel
scan of this table. If not set, the system will determine a value based
on the relation size. The actual number of workers chosen by the planner
may be less, for example due to
the setting of <xref linkend="guc-max-worker-processes">.
Add a 'parallel_degree' reloption. The code that estimates what parallel degree should be uesd for the scan of a relation is currently rather stupid, so add a parallel_degree reloption that can be used to override the planner's rather limited judgement. Julien Rouhaud, reviewed by David Rowley, James Sewell, Amit Kapila, and me. Some further hacking by me.
2016-04-08 17:14:56 +02:00
</para>
</listitem>
</varlistentry>
Allow reloption names to have qualifiers, initially supporting a TOAST qualifier, and add support for this in pg_dump. This allows TOAST tables to have user-defined fillfactor, and will also enable us to move the autovacuum parameters to reloptions without taking away the possibility of setting values for TOAST tables.
2009-02-02 20:31:40 +01:00
<varlistentry>
Update autovacuum to use reloptions instead of a system catalog, for per-table overrides of parameters. This removes a whole class of problems related to misusing the catalog, and perhaps more importantly, gives us pg_dump support for the parameters. Based on a patch by Euler Taveira de Oliveira, heavily reworked by me.
2009-02-09 21:57:59 +01:00
<term><literal>autovacuum_enabled</>, <literal>toast.autovacuum_enabled</literal> (<type>boolean</>)</term>
<listitem>
<para>
Improve documentation around autovacuum-related storage parameters. These were discussed in three different sections of the manual, which unsurprisingly had diverged over time; and the descriptions of individual variables lacked stylistic consistency even within each section (and frequently weren't in very good English anyway). Clean up the mess, and remove some of the redundant information in hopes that future additions will be less likely to re-introduce inconsistency. For instance I see no need for maintenance.sgml to include its very own list of all the autovacuum storage parameters, especially since that list was already incomplete.
2015-11-11 23:13:38 +01:00
Enables or disables the autovacuum daemon for a particular table.
If true, the autovacuum daemon will perform automatic <command>VACUUM</>
and/or <command>ANALYZE</> operations on this table following the rules
discussed in <xref linkend="autovacuum">.
Update autovacuum to use reloptions instead of a system catalog, for per-table overrides of parameters. This removes a whole class of problems related to misusing the catalog, and perhaps more importantly, gives us pg_dump support for the parameters. Based on a patch by Euler Taveira de Oliveira, heavily reworked by me.
2009-02-09 21:57:59 +01:00
If false, this table will not be autovacuumed, except to prevent
Improve documentation around autovacuum-related storage parameters. These were discussed in three different sections of the manual, which unsurprisingly had diverged over time; and the descriptions of individual variables lacked stylistic consistency even within each section (and frequently weren't in very good English anyway). Clean up the mess, and remove some of the redundant information in hopes that future additions will be less likely to re-introduce inconsistency. For instance I see no need for maintenance.sgml to include its very own list of all the autovacuum storage parameters, especially since that list was already incomplete.
2015-11-11 23:13:38 +01:00
transaction ID wraparound. See <xref linkend="vacuum-for-wraparound"> for
Update autovacuum to use reloptions instead of a system catalog, for per-table overrides of parameters. This removes a whole class of problems related to misusing the catalog, and perhaps more importantly, gives us pg_dump support for the parameters. Based on a patch by Euler Taveira de Oliveira, heavily reworked by me.
2009-02-09 21:57:59 +01:00
more about wraparound prevention.
Improve documentation around autovacuum-related storage parameters. These were discussed in three different sections of the manual, which unsurprisingly had diverged over time; and the descriptions of individual variables lacked stylistic consistency even within each section (and frequently weren't in very good English anyway). Clean up the mess, and remove some of the redundant information in hopes that future additions will be less likely to re-introduce inconsistency. For instance I see no need for maintenance.sgml to include its very own list of all the autovacuum storage parameters, especially since that list was already incomplete.
2015-11-11 23:13:38 +01:00
Note that the autovacuum daemon does not run at all (except to prevent
transaction ID wraparound) if the <xref linkend="guc-autovacuum">
parameter is false; setting individual tables' storage parameters does
not override that. Therefore there is seldom much point in explicitly
setting this storage parameter to <literal>true</>, only
to <literal>false</>.
Update autovacuum to use reloptions instead of a system catalog, for per-table overrides of parameters. This removes a whole class of problems related to misusing the catalog, and perhaps more importantly, gives us pg_dump support for the parameters. Based on a patch by Euler Taveira de Oliveira, heavily reworked by me.
2009-02-09 21:57:59 +01:00
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>autovacuum_vacuum_threshold</>, <literal>toast.autovacuum_vacuum_threshold</literal> (<type>integer</>)</term>
<listitem>
<para>
Improve documentation around autovacuum-related storage parameters. These were discussed in three different sections of the manual, which unsurprisingly had diverged over time; and the descriptions of individual variables lacked stylistic consistency even within each section (and frequently weren't in very good English anyway). Clean up the mess, and remove some of the redundant information in hopes that future additions will be less likely to re-introduce inconsistency. For instance I see no need for maintenance.sgml to include its very own list of all the autovacuum storage parameters, especially since that list was already incomplete.
2015-11-11 23:13:38 +01:00
Per-table value for <xref linkend="guc-autovacuum-vacuum-threshold">
parameter.
Update autovacuum to use reloptions instead of a system catalog, for per-table overrides of parameters. This removes a whole class of problems related to misusing the catalog, and perhaps more importantly, gives us pg_dump support for the parameters. Based on a patch by Euler Taveira de Oliveira, heavily reworked by me.
2009-02-09 21:57:59 +01:00
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>autovacuum_vacuum_scale_factor</>, <literal>toast.autovacuum_vacuum_scale_factor</literal> (<type>float4</>)</term>
<listitem>
<para>
Improve documentation around autovacuum-related storage parameters. These were discussed in three different sections of the manual, which unsurprisingly had diverged over time; and the descriptions of individual variables lacked stylistic consistency even within each section (and frequently weren't in very good English anyway). Clean up the mess, and remove some of the redundant information in hopes that future additions will be less likely to re-introduce inconsistency. For instance I see no need for maintenance.sgml to include its very own list of all the autovacuum storage parameters, especially since that list was already incomplete.
2015-11-11 23:13:38 +01:00
Per-table value for <xref linkend="guc-autovacuum-vacuum-scale-factor">
parameter.
Update autovacuum to use reloptions instead of a system catalog, for per-table overrides of parameters. This removes a whole class of problems related to misusing the catalog, and perhaps more importantly, gives us pg_dump support for the parameters. Based on a patch by Euler Taveira de Oliveira, heavily reworked by me.
2009-02-09 21:57:59 +01:00
</para>
</listitem>
</varlistentry>
<varlistentry>
Ensure default-only storage parameters for TOAST relations to be initialized with proper values. Affected parameters are fillfactor, analyze_threshold, and analyze_scale_factor. Especially uninitialized fillfactor caused inefficient page usage because we built a StdRdOptions struct in which fillfactor is zero if any reloption is set for the toast table. In addition, we disallow toast.autovacuum_analyze_threshold and toast.autovacuum_analyze_scale_factor because we didn't actually support them; they are always ignored. Report by Rumko on pgsql-bugs on 12 May 2010. Analysis by Tom Lane and Alvaro Herrera. Patch by me. Backpatch to 8.4.
2010-06-07 04:59:02 +02:00
<term><literal>autovacuum_analyze_threshold</> (<type>integer</>)</term>
Update autovacuum to use reloptions instead of a system catalog, for per-table overrides of parameters. This removes a whole class of problems related to misusing the catalog, and perhaps more importantly, gives us pg_dump support for the parameters. Based on a patch by Euler Taveira de Oliveira, heavily reworked by me.
2009-02-09 21:57:59 +01:00
<listitem>
<para>
Improve documentation around autovacuum-related storage parameters. These were discussed in three different sections of the manual, which unsurprisingly had diverged over time; and the descriptions of individual variables lacked stylistic consistency even within each section (and frequently weren't in very good English anyway). Clean up the mess, and remove some of the redundant information in hopes that future additions will be less likely to re-introduce inconsistency. For instance I see no need for maintenance.sgml to include its very own list of all the autovacuum storage parameters, especially since that list was already incomplete.
2015-11-11 23:13:38 +01:00
Per-table value for <xref linkend="guc-autovacuum-analyze-threshold">
parameter.
Update autovacuum to use reloptions instead of a system catalog, for per-table overrides of parameters. This removes a whole class of problems related to misusing the catalog, and perhaps more importantly, gives us pg_dump support for the parameters. Based on a patch by Euler Taveira de Oliveira, heavily reworked by me.
2009-02-09 21:57:59 +01:00
</para>
</listitem>
</varlistentry>
<varlistentry>
Ensure default-only storage parameters for TOAST relations to be initialized with proper values. Affected parameters are fillfactor, analyze_threshold, and analyze_scale_factor. Especially uninitialized fillfactor caused inefficient page usage because we built a StdRdOptions struct in which fillfactor is zero if any reloption is set for the toast table. In addition, we disallow toast.autovacuum_analyze_threshold and toast.autovacuum_analyze_scale_factor because we didn't actually support them; they are always ignored. Report by Rumko on pgsql-bugs on 12 May 2010. Analysis by Tom Lane and Alvaro Herrera. Patch by me. Backpatch to 8.4.
2010-06-07 04:59:02 +02:00
<term><literal>autovacuum_analyze_scale_factor</> (<type>float4</>)</term>
Update autovacuum to use reloptions instead of a system catalog, for per-table overrides of parameters. This removes a whole class of problems related to misusing the catalog, and perhaps more importantly, gives us pg_dump support for the parameters. Based on a patch by Euler Taveira de Oliveira, heavily reworked by me.
2009-02-09 21:57:59 +01:00
<listitem>
<para>
Improve documentation around autovacuum-related storage parameters. These were discussed in three different sections of the manual, which unsurprisingly had diverged over time; and the descriptions of individual variables lacked stylistic consistency even within each section (and frequently weren't in very good English anyway). Clean up the mess, and remove some of the redundant information in hopes that future additions will be less likely to re-introduce inconsistency. For instance I see no need for maintenance.sgml to include its very own list of all the autovacuum storage parameters, especially since that list was already incomplete.
2015-11-11 23:13:38 +01:00
Per-table value for <xref linkend="guc-autovacuum-analyze-scale-factor">
parameter.
Update autovacuum to use reloptions instead of a system catalog, for per-table overrides of parameters. This removes a whole class of problems related to misusing the catalog, and perhaps more importantly, gives us pg_dump support for the parameters. Based on a patch by Euler Taveira de Oliveira, heavily reworked by me.
2009-02-09 21:57:59 +01:00
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>autovacuum_vacuum_cost_delay</>, <literal>toast.autovacuum_vacuum_cost_delay</literal> (<type>integer</>)</term>
<listitem>
<para>
Improve documentation around autovacuum-related storage parameters. These were discussed in three different sections of the manual, which unsurprisingly had diverged over time; and the descriptions of individual variables lacked stylistic consistency even within each section (and frequently weren't in very good English anyway). Clean up the mess, and remove some of the redundant information in hopes that future additions will be less likely to re-introduce inconsistency. For instance I see no need for maintenance.sgml to include its very own list of all the autovacuum storage parameters, especially since that list was already incomplete.
2015-11-11 23:13:38 +01:00
Per-table value for <xref linkend="guc-autovacuum-vacuum-cost-delay">
parameter.
Update autovacuum to use reloptions instead of a system catalog, for per-table overrides of parameters. This removes a whole class of problems related to misusing the catalog, and perhaps more importantly, gives us pg_dump support for the parameters. Based on a patch by Euler Taveira de Oliveira, heavily reworked by me.
2009-02-09 21:57:59 +01:00
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>autovacuum_vacuum_cost_limit</>, <literal>toast.autovacuum_vacuum_cost_limit</literal> (<type>integer</>)</term>
<listitem>
<para>
Improve documentation around autovacuum-related storage parameters. These were discussed in three different sections of the manual, which unsurprisingly had diverged over time; and the descriptions of individual variables lacked stylistic consistency even within each section (and frequently weren't in very good English anyway). Clean up the mess, and remove some of the redundant information in hopes that future additions will be less likely to re-introduce inconsistency. For instance I see no need for maintenance.sgml to include its very own list of all the autovacuum storage parameters, especially since that list was already incomplete.
2015-11-11 23:13:38 +01:00
Per-table value for <xref linkend="guc-autovacuum-vacuum-cost-limit">
parameter.
Update autovacuum to use reloptions instead of a system catalog, for per-table overrides of parameters. This removes a whole class of problems related to misusing the catalog, and perhaps more importantly, gives us pg_dump support for the parameters. Based on a patch by Euler Taveira de Oliveira, heavily reworked by me.
2009-02-09 21:57:59 +01:00
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>autovacuum_freeze_min_age</>, <literal>toast.autovacuum_freeze_min_age</literal> (<type>integer</>)</term>
<listitem>
<para>
Improve documentation around autovacuum-related storage parameters. These were discussed in three different sections of the manual, which unsurprisingly had diverged over time; and the descriptions of individual variables lacked stylistic consistency even within each section (and frequently weren't in very good English anyway). Clean up the mess, and remove some of the redundant information in hopes that future additions will be less likely to re-introduce inconsistency. For instance I see no need for maintenance.sgml to include its very own list of all the autovacuum storage parameters, especially since that list was already incomplete.
2015-11-11 23:13:38 +01:00
Per-table value for <xref linkend="guc-vacuum-freeze-min-age">
parameter. Note that autovacuum will ignore
per-table <literal>autovacuum_freeze_min_age</> parameters that are
larger than half the
system-wide <xref linkend="guc-autovacuum-freeze-max-age"> setting.
Update autovacuum to use reloptions instead of a system catalog, for per-table overrides of parameters. This removes a whole class of problems related to misusing the catalog, and perhaps more importantly, gives us pg_dump support for the parameters. Based on a patch by Euler Taveira de Oliveira, heavily reworked by me.
2009-02-09 21:57:59 +01:00
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>autovacuum_freeze_max_age</>, <literal>toast.autovacuum_freeze_max_age</literal> (<type>integer</>)</term>
<listitem>
<para>
Improve documentation around autovacuum-related storage parameters. These were discussed in three different sections of the manual, which unsurprisingly had diverged over time; and the descriptions of individual variables lacked stylistic consistency even within each section (and frequently weren't in very good English anyway). Clean up the mess, and remove some of the redundant information in hopes that future additions will be less likely to re-introduce inconsistency. For instance I see no need for maintenance.sgml to include its very own list of all the autovacuum storage parameters, especially since that list was already incomplete.
2015-11-11 23:13:38 +01:00
Per-table value for <xref linkend="guc-autovacuum-freeze-max-age">
parameter. Note that autovacuum will ignore
per-table <literal>autovacuum_freeze_max_age</> parameters that are
larger than the system-wide setting (it can only be set smaller).
Update autovacuum to use reloptions instead of a system catalog, for per-table overrides of parameters. This removes a whole class of problems related to misusing the catalog, and perhaps more importantly, gives us pg_dump support for the parameters. Based on a patch by Euler Taveira de Oliveira, heavily reworked by me.
2009-02-09 21:57:59 +01:00
</para>
</listitem>
</varlistentry>
<varlistentry>
Fix documentation on the toast.fillfactor reloption: it doesn't exist. Per note from Zoltan Boszormenyi.
2009-10-27 14:58:28 +01:00
<term><literal>autovacuum_freeze_table_age</literal>, <literal>toast.autovacuum_freeze_table_age</literal> (<type>integer</type>)</term>
Allow reloption names to have qualifiers, initially supporting a TOAST qualifier, and add support for this in pg_dump. This allows TOAST tables to have user-defined fillfactor, and will also enable us to move the autovacuum parameters to reloptions without taking away the possibility of setting values for TOAST tables.
2009-02-02 20:31:40 +01:00
<listitem>
<para>
Improve documentation around autovacuum-related storage parameters. These were discussed in three different sections of the manual, which unsurprisingly had diverged over time; and the descriptions of individual variables lacked stylistic consistency even within each section (and frequently weren't in very good English anyway). Clean up the mess, and remove some of the redundant information in hopes that future additions will be less likely to re-introduce inconsistency. For instance I see no need for maintenance.sgml to include its very own list of all the autovacuum storage parameters, especially since that list was already incomplete.
2015-11-11 23:13:38 +01:00
Per-table value for <xref linkend="guc-vacuum-freeze-table-age">
parameter.
Allow reloption names to have qualifiers, initially supporting a TOAST qualifier, and add support for this in pg_dump. This allows TOAST tables to have user-defined fillfactor, and will also enable us to move the autovacuum parameters to reloptions without taking away the possibility of setting values for TOAST tables.
2009-02-02 20:31:40 +01:00
</para>
</listitem>
Documentation fixes for FILLFACTOR patch. Minor other editorialization.
2006-07-04 20:07:24 +02:00
</varlistentry>
Separate multixact freezing parameters from xid's Previously we were piggybacking on transaction ID parameters to freeze multixacts; but since there isn't necessarily any relationship between rates of Xid and multixact consumption, this turns out not to be a good idea. Therefore, we now have multixact-specific freezing parameters: vacuum_multixact_freeze_min_age: when to remove multis as we come across them in vacuum (default to 5 million, i.e. early in comparison to Xid's default of 50 million) vacuum_multixact_freeze_table_age: when to force whole-table scans instead of scanning only the pages marked as not all visible in visibility map (default to 150 million, same as for Xids). Whichever of both which reaches the 150 million mark earlier will cause a whole-table scan. autovacuum_multixact_freeze_max_age: when for cause emergency, uninterruptible whole-table scans (default to 400 million, double as that for Xids). This means there shouldn't be more frequent emergency vacuuming than previously, unless multixacts are being used very rapidly. Backpatch to 9.3 where multixacts were made to persist enough to require freezing. To avoid an ABI break in 9.3, VacuumStmt has a couple of fields in an unnatural place, and StdRdOptions is split in two so that the newly added fields can go at the end. Patch by me, reviewed by Robert Haas, with additional input from Andres Freund and Tom Lane.
2014-02-13 23:30:30 +01:00
<varlistentry>
<term><literal>autovacuum_multixact_freeze_min_age</literal>, <literal>toast.autovacuum_multixact_freeze_min_age</literal> (<type>integer</type>)</term>
<listitem>
<para>
Improve documentation around autovacuum-related storage parameters. These were discussed in three different sections of the manual, which unsurprisingly had diverged over time; and the descriptions of individual variables lacked stylistic consistency even within each section (and frequently weren't in very good English anyway). Clean up the mess, and remove some of the redundant information in hopes that future additions will be less likely to re-introduce inconsistency. For instance I see no need for maintenance.sgml to include its very own list of all the autovacuum storage parameters, especially since that list was already incomplete.
2015-11-11 23:13:38 +01:00
Per-table value for <xref linkend="guc-vacuum-multixact-freeze-min-age">
parameter. Note that autovacuum will ignore
per-table <literal>autovacuum_multixact_freeze_min_age</> parameters
that are larger than half the
Separate multixact freezing parameters from xid's Previously we were piggybacking on transaction ID parameters to freeze multixacts; but since there isn't necessarily any relationship between rates of Xid and multixact consumption, this turns out not to be a good idea. Therefore, we now have multixact-specific freezing parameters: vacuum_multixact_freeze_min_age: when to remove multis as we come across them in vacuum (default to 5 million, i.e. early in comparison to Xid's default of 50 million) vacuum_multixact_freeze_table_age: when to force whole-table scans instead of scanning only the pages marked as not all visible in visibility map (default to 150 million, same as for Xids). Whichever of both which reaches the 150 million mark earlier will cause a whole-table scan. autovacuum_multixact_freeze_max_age: when for cause emergency, uninterruptible whole-table scans (default to 400 million, double as that for Xids). This means there shouldn't be more frequent emergency vacuuming than previously, unless multixacts are being used very rapidly. Backpatch to 9.3 where multixacts were made to persist enough to require freezing. To avoid an ABI break in 9.3, VacuumStmt has a couple of fields in an unnatural place, and StdRdOptions is split in two so that the newly added fields can go at the end. Patch by me, reviewed by Robert Haas, with additional input from Andres Freund and Tom Lane.
2014-02-13 23:30:30 +01:00
system-wide <xref linkend="guc-autovacuum-multixact-freeze-max-age">
setting.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>autovacuum_multixact_freeze_max_age</literal>, <literal>toast.autovacuum_multixact_freeze_max_age</literal> (<type>integer</type>)</term>
<listitem>
<para>
Improve documentation around autovacuum-related storage parameters. These were discussed in three different sections of the manual, which unsurprisingly had diverged over time; and the descriptions of individual variables lacked stylistic consistency even within each section (and frequently weren't in very good English anyway). Clean up the mess, and remove some of the redundant information in hopes that future additions will be less likely to re-introduce inconsistency. For instance I see no need for maintenance.sgml to include its very own list of all the autovacuum storage parameters, especially since that list was already incomplete.
2015-11-11 23:13:38 +01:00
Per-table value
for <xref linkend="guc-autovacuum-multixact-freeze-max-age"> parameter.
Note that autovacuum will ignore
per-table <literal>autovacuum_multixact_freeze_max_age</> parameters
that are larger than the system-wide setting (it can only be set
smaller).
Separate multixact freezing parameters from xid's Previously we were piggybacking on transaction ID parameters to freeze multixacts; but since there isn't necessarily any relationship between rates of Xid and multixact consumption, this turns out not to be a good idea. Therefore, we now have multixact-specific freezing parameters: vacuum_multixact_freeze_min_age: when to remove multis as we come across them in vacuum (default to 5 million, i.e. early in comparison to Xid's default of 50 million) vacuum_multixact_freeze_table_age: when to force whole-table scans instead of scanning only the pages marked as not all visible in visibility map (default to 150 million, same as for Xids). Whichever of both which reaches the 150 million mark earlier will cause a whole-table scan. autovacuum_multixact_freeze_max_age: when for cause emergency, uninterruptible whole-table scans (default to 400 million, double as that for Xids). This means there shouldn't be more frequent emergency vacuuming than previously, unless multixacts are being used very rapidly. Backpatch to 9.3 where multixacts were made to persist enough to require freezing. To avoid an ABI break in 9.3, VacuumStmt has a couple of fields in an unnatural place, and StdRdOptions is split in two so that the newly added fields can go at the end. Patch by me, reviewed by Robert Haas, with additional input from Andres Freund and Tom Lane.
2014-02-13 23:30:30 +01:00
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>autovacuum_multixact_freeze_table_age</literal>, <literal>toast.autovacuum_multixact_freeze_table_age</literal> (<type>integer</type>)</term>
<listitem>
<para>
Improve documentation around autovacuum-related storage parameters. These were discussed in three different sections of the manual, which unsurprisingly had diverged over time; and the descriptions of individual variables lacked stylistic consistency even within each section (and frequently weren't in very good English anyway). Clean up the mess, and remove some of the redundant information in hopes that future additions will be less likely to re-introduce inconsistency. For instance I see no need for maintenance.sgml to include its very own list of all the autovacuum storage parameters, especially since that list was already incomplete.
2015-11-11 23:13:38 +01:00
Per-table value
for <xref linkend="guc-vacuum-multixact-freeze-table-age"> parameter.
Separate multixact freezing parameters from xid's Previously we were piggybacking on transaction ID parameters to freeze multixacts; but since there isn't necessarily any relationship between rates of Xid and multixact consumption, this turns out not to be a good idea. Therefore, we now have multixact-specific freezing parameters: vacuum_multixact_freeze_min_age: when to remove multis as we come across them in vacuum (default to 5 million, i.e. early in comparison to Xid's default of 50 million) vacuum_multixact_freeze_table_age: when to force whole-table scans instead of scanning only the pages marked as not all visible in visibility map (default to 150 million, same as for Xids). Whichever of both which reaches the 150 million mark earlier will cause a whole-table scan. autovacuum_multixact_freeze_max_age: when for cause emergency, uninterruptible whole-table scans (default to 400 million, double as that for Xids). This means there shouldn't be more frequent emergency vacuuming than previously, unless multixacts are being used very rapidly. Backpatch to 9.3 where multixacts were made to persist enough to require freezing. To avoid an ABI break in 9.3, VacuumStmt has a couple of fields in an unnatural place, and StdRdOptions is split in two so that the newly added fields can go at the end. Patch by me, reviewed by Robert Haas, with additional input from Andres Freund and Tom Lane.
2014-02-13 23:30:30 +01:00
</para>
</listitem>
</varlistentry>
Add log_min_autovacuum_duration per-table option This is useful to control autovacuum log volume, for situations where monitoring only a set of tables is necessary. Author: Michael Paquier Reviewed by: A team led by Naoya Anzai (also including Akira Kurosawa, Taiki Kondo, Huong Dangminh), Fujii Masao.
2015-04-03 16:55:50 +02:00
<varlistentry>
<term><literal>log_autovacuum_min_duration</literal>, <literal>toast.log_autovacuum_min_duration</literal> (<type>integer</type>)</term>
<listitem>
<para>
Improve documentation around autovacuum-related storage parameters. These were discussed in three different sections of the manual, which unsurprisingly had diverged over time; and the descriptions of individual variables lacked stylistic consistency even within each section (and frequently weren't in very good English anyway). Clean up the mess, and remove some of the redundant information in hopes that future additions will be less likely to re-introduce inconsistency. For instance I see no need for maintenance.sgml to include its very own list of all the autovacuum storage parameters, especially since that list was already incomplete.
2015-11-11 23:13:38 +01:00
Per-table value for <xref linkend="guc-log-autovacuum-min-duration">
parameter.
Add log_min_autovacuum_duration per-table option This is useful to control autovacuum log volume, for situations where monitoring only a set of tables is necessary. Author: Michael Paquier Reviewed by: A team led by Naoya Anzai (also including Akira Kurosawa, Taiki Kondo, Huong Dangminh), Fujii Masao.
2015-04-03 16:55:50 +02:00
</para>
</listitem>
</varlistentry>
Documentation for logical decoding. Craig Ringer, Andres Freund, Christian Kruse, with edits by me.
2014-03-18 18:20:01 +01:00
<varlistentry>
<term><literal>user_catalog_table</literal> (<type>boolean</type>)</term>
<listitem>
<para>
Improve documentation around autovacuum-related storage parameters. These were discussed in three different sections of the manual, which unsurprisingly had diverged over time; and the descriptions of individual variables lacked stylistic consistency even within each section (and frequently weren't in very good English anyway). Clean up the mess, and remove some of the redundant information in hopes that future additions will be less likely to re-introduce inconsistency. For instance I see no need for maintenance.sgml to include its very own list of all the autovacuum storage parameters, especially since that list was already incomplete.
2015-11-11 23:13:38 +01:00
Declare the table as an additional catalog table for purposes of
Documentation for logical decoding. Craig Ringer, Andres Freund, Christian Kruse, with edits by me.
2014-03-18 18:20:01 +01:00
logical replication. See
<xref linkend="logicaldecoding-capabilities"> for details.
Add log_min_autovacuum_duration per-table option This is useful to control autovacuum log volume, for situations where monitoring only a set of tables is necessary. Author: Michael Paquier Reviewed by: A team led by Naoya Anzai (also including Akira Kurosawa, Taiki Kondo, Huong Dangminh), Fujii Masao.
2015-04-03 16:55:50 +02:00
This parameter cannot be set for TOAST tables.
Documentation for logical decoding. Craig Ringer, Andres Freund, Christian Kruse, with edits by me.
2014-03-18 18:20:01 +01:00
</para>
</listitem>
</varlistentry>
Documentation fixes for FILLFACTOR patch. Minor other editorialization.
2006-07-04 20:07:24 +02:00
</variablelist>
</refsect2>
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
</refsect1>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<refsect1 id="SQL-CREATETABLE-notes">
<title>Notes</title>
First version of files from Oliver Elphick.
1998-07-14 05:47:34 +02:00
Minor updates for release. Split reference pages for CREATE TABLE AS and SELECT INTO to allow psgml (the emacs parser) to handle parsing.
1999-06-14 09:37:05 +02:00
<para>
This patch adds a new GUC var, "default_with_oids", which follows the proposal for eventually deprecating OIDs on user tables that I posted earlier to pgsql-hackers. pg_dump now always specifies WITH OIDS or WITHOUT OIDS when dumping a table. The documentation has been updated. Neil Conway
2003-12-01 23:08:02 +01:00
Using OIDs in new applications is not recommended: where
Identity columns This is the SQL standard-conforming variant of PostgreSQL's serial columns. It fixes a few usability issues that serial columns have: - CREATE TABLE / LIKE copies default but refers to same sequence - cannot add/drop serialness with ALTER TABLE - dropping default does not drop sequence - need to grant separate privileges to sequence - other slight weirdnesses because serial is some kind of special macro Reviewed-by: Vitaly Burovoy <vitaly.burovoy@gmail.com>
2017-04-06 14:33:16 +02:00
possible, using an identity column or other sequence
This patch adds a new GUC var, "default_with_oids", which follows the proposal for eventually deprecating OIDs on user tables that I posted earlier to pgsql-hackers. pg_dump now always specifies WITH OIDS or WITHOUT OIDS when dumping a table. The documentation has been updated. Neil Conway
2003-12-01 23:08:02 +01:00
generator as the table's primary key is preferred. However, if
More minor updates and copy-editing.
2005-01-04 01:39:53 +01:00
your application does make use of OIDs to identify specific
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
rows of a table, it is recommended to create a unique constraint
on the <structfield>oid</> column of that table, to ensure that
OIDs in the table will indeed uniquely identify rows even after
counter wraparound. Avoid assuming that OIDs are unique across
tables; if you need a database-wide unique identifier, use the
combination of <structfield>tableoid</> and row OID for the
This patch adds a new GUC var, "default_with_oids", which follows the proposal for eventually deprecating OIDs on user tables that I posted earlier to pgsql-hackers. pg_dump now always specifies WITH OIDS or WITHOUT OIDS when dumping a table. The documentation has been updated. Neil Conway
2003-12-01 23:08:02 +01:00
purpose.
Clean up to ensure tag completion as required by the newest versions of Norm's Modular Style Sheets and jade/docbook. From Vince Vielhaber <vev@michvhf.com>.
1998-12-29 03:24:47 +01:00
</para>
Editing and markup cleanup.
1998-09-22 17:48:03 +02:00
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<tip>
<para>
Documentation fixes for FILLFACTOR patch. Minor other editorialization.
2006-07-04 20:07:24 +02:00
The use of <literal>OIDS=FALSE</literal> is not recommended
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
for tables with no primary key, since without either an OID or a
unique data key, it is difficult to identify specific rows.
</para>
</tip>
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
Minor updates for release. Split reference pages for CREATE TABLE AS and SELECT INTO to allow psgml (the emacs parser) to handle parsing.
1999-06-14 09:37:05 +02:00
<para>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<productname>PostgreSQL</productname> automatically creates an
index for each unique constraint and primary key constraint to
More minor updates and copy-editing.
2005-01-04 01:39:53 +01:00
enforce uniqueness. Thus, it is not necessary to create an
index explicitly for primary key columns. (See <xref
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02:00
linkend="sql-createindex"> for more information.)
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
</para>
Attached is are diffs for CREATE/ALTER table doc I've forgotten in my mailbox (sorry). Haven't tried to apply and since I don't have working sgml stuff cannot check. Jan
2000-04-11 16:43:54 +02:00
<para>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
Unique constraints and primary keys are not inherited in the
current implementation. This makes the combination of
Spell-check and markup police
2002-01-20 23:19:57 +01:00
inheritance and unique constraints rather dysfunctional.
Attached is are diffs for CREATE/ALTER table doc I've forgotten in my mailbox (sorry). Haven't tried to apply and since I don't have working sgml stuff cannot check. Jan
2000-04-11 16:43:54 +02:00
</para>
More minor updates and copy-editing.
2005-01-04 01:39:53 +01:00
Documentation fixes for FILLFACTOR patch. Minor other editorialization.
2006-07-04 20:07:24 +02:00
<para>
A table cannot have more than 1600 columns. (In practice, the
effective limit is usually lower because of tuple-length constraints.)
</para>
More minor updates and copy-editing.
2005-01-04 01:39:53 +01:00
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
</refsect1>
Attached is are diffs for CREATE/ALTER table doc I've forgotten in my mailbox (sorry). Haven't tried to apply and since I don't have working sgml stuff cannot check. Jan
2000-04-11 16:43:54 +02:00
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<refsect1 id="SQL-CREATETABLE-examples">
<title>Examples</title>
Minor updates for release. Split reference pages for CREATE TABLE AS and SELECT INTO to allow psgml (the emacs parser) to handle parsing.
1999-06-14 09:37:05 +02:00
<para>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
Create table <structname>films</> and table
<structname>distributors</>:
First version of files from Oliver Elphick.
1998-07-14 05:47:34 +02:00
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<programlisting>
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
CREATE TABLE films (
More editing of reference pages.
2003-04-22 12:08:08 +02:00
code char(5) CONSTRAINT firstkey PRIMARY KEY,
title varchar(40) NOT NULL,
did integer NOT NULL,
date_prod date,
kind varchar(10),
len interval hour to minute
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
);
First version of files from Oliver Elphick.
1998-07-14 05:47:34 +02:00
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
CREATE TABLE distributors (
Identity columns This is the SQL standard-conforming variant of PostgreSQL's serial columns. It fixes a few usability issues that serial columns have: - CREATE TABLE / LIKE copies default but refers to same sequence - cannot add/drop serialness with ALTER TABLE - dropping default does not drop sequence - need to grant separate privileges to sequence - other slight weirdnesses because serial is some kind of special macro Reviewed-by: Vitaly Burovoy <vitaly.burovoy@gmail.com>
2017-04-06 14:33:16 +02:00
did integer PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY,
More editing of reference pages.
2003-04-22 12:08:08 +02:00
name varchar(40) NOT NULL CHECK (name &lt;&gt; '')
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
);
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
</programlisting>
Minor updates for release. Split reference pages for CREATE TABLE AS and SELECT INTO to allow psgml (the emacs parser) to handle parsing.
1999-06-14 09:37:05 +02:00
</para>
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
<para>
Create a table with a 2-dimensional array:
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<programlisting>
Fix example, change table name from 'array' to 'array_int'.
2005-01-05 19:03:19 +01:00
CREATE TABLE array_int (
More editing of reference pages.
2003-04-22 12:08:08 +02:00
vector int[][]
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
);
</programlisting>
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
</para>
Minor updates for release. Split reference pages for CREATE TABLE AS and SELECT INTO to allow psgml (the emacs parser) to handle parsing.
1999-06-14 09:37:05 +02:00
<para>
More editing of reference pages.
2003-04-22 12:08:08 +02:00
Define a unique table constraint for the table
<literal>films</literal>. Unique table constraints can be defined
Consistenly use colons before '<programlisting>' blocks, where appropriate.
2007-02-01 01:28:19 +01:00
on one or more columns of the table:
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<programlisting>
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
CREATE TABLE films (
More editing of reference pages.
2003-04-22 12:08:08 +02:00
code char(5),
title varchar(40),
did integer,
date_prod date,
kind varchar(10),
len interval hour to minute,
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
CONSTRAINT production UNIQUE(date_prod)
);
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
</programlisting>
Minor updates for release. Split reference pages for CREATE TABLE AS and SELECT INTO to allow psgml (the emacs parser) to handle parsing.
1999-06-14 09:37:05 +02:00
</para>
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
Minor updates for release. Split reference pages for CREATE TABLE AS and SELECT INTO to allow psgml (the emacs parser) to handle parsing.
1999-06-14 09:37:05 +02:00
<para>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
Define a check column constraint:
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<programlisting>
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
CREATE TABLE distributors (
More < and > changes to ampersands. 8.0.X and HEAD.
2005-01-23 00:22:19 +01:00
did integer CHECK (did &gt; 100),
More editing of reference pages.
2003-04-22 12:08:08 +02:00
name varchar(40)
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
);
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
</programlisting>
Minor updates for release. Split reference pages for CREATE TABLE AS and SELECT INTO to allow psgml (the emacs parser) to handle parsing.
1999-06-14 09:37:05 +02:00
</para>
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
Minor updates for release. Split reference pages for CREATE TABLE AS and SELECT INTO to allow psgml (the emacs parser) to handle parsing.
1999-06-14 09:37:05 +02:00
<para>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
Define a check table constraint:
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<programlisting>
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
CREATE TABLE distributors (
More editing of reference pages.
2003-04-22 12:08:08 +02:00
did integer,
name varchar(40)
More < and > changes to ampersands. 8.0.X and HEAD.
2005-01-23 00:22:19 +01:00
CONSTRAINT con1 CHECK (did &gt; 100 AND name &lt;&gt; '')
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
);
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
</programlisting>
Minor updates for release. Split reference pages for CREATE TABLE AS and SELECT INTO to allow psgml (the emacs parser) to handle parsing.
1999-06-14 09:37:05 +02:00
</para>
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
Minor updates for release. Split reference pages for CREATE TABLE AS and SELECT INTO to allow psgml (the emacs parser) to handle parsing.
1999-06-14 09:37:05 +02:00
<para>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
Define a primary key table constraint for the table
Documentation fixes for FILLFACTOR patch. Minor other editorialization.
2006-07-04 20:07:24 +02:00
<structname>films</>:
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<programlisting>
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
CREATE TABLE films (
More editing of reference pages.
2003-04-22 12:08:08 +02:00
code char(5),
title varchar(40),
did integer,
date_prod date,
kind varchar(10),
len interval hour to minute,
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
CONSTRAINT code_title PRIMARY KEY(code,title)
);
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
</programlisting>
Minor updates for release. Split reference pages for CREATE TABLE AS and SELECT INTO to allow psgml (the emacs parser) to handle parsing.
1999-06-14 09:37:05 +02:00
</para>
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
Minor updates for release. Split reference pages for CREATE TABLE AS and SELECT INTO to allow psgml (the emacs parser) to handle parsing.
1999-06-14 09:37:05 +02:00
<para>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
Define a primary key constraint for table
<structname>distributors</>. The following two examples are
equivalent, the first using the table constraint syntax, the second
Documentation fixes for FILLFACTOR patch. Minor other editorialization.
2006-07-04 20:07:24 +02:00
the column constraint syntax:
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<programlisting>
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
CREATE TABLE distributors (
More editing of reference pages.
2003-04-22 12:08:08 +02:00
did integer,
name varchar(40),
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
PRIMARY KEY(did)
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
);
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
CREATE TABLE distributors (
More editing of reference pages.
2003-04-22 12:08:08 +02:00
did integer PRIMARY KEY,
name varchar(40)
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
);
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
</programlisting>
Minor updates for release. Split reference pages for CREATE TABLE AS and SELECT INTO to allow psgml (the emacs parser) to handle parsing.
1999-06-14 09:37:05 +02:00
</para>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<para>
Documentation fixes for FILLFACTOR patch. Minor other editorialization.
2006-07-04 20:07:24 +02:00
Assign a literal constant default value for the column
<literal>name</literal>, arrange for the default value of column
More editing of reference pages.
2003-04-22 12:08:08 +02:00
<literal>did</literal> to be generated by selecting the next value
Documentation fixes for FILLFACTOR patch. Minor other editorialization.
2006-07-04 20:07:24 +02:00
of a sequence object, and make the default value of
More editing of reference pages.
2003-04-22 12:08:08 +02:00
<literal>modtime</literal> be the time at which the row is
Documentation fixes for FILLFACTOR patch. Minor other editorialization.
2006-07-04 20:07:24 +02:00
inserted:
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<programlisting>
CREATE TABLE distributors (
More editing of reference pages.
2003-04-22 12:08:08 +02:00
name varchar(40) DEFAULT 'Luso Films',
did integer DEFAULT nextval('distributors_serial'),
modtime timestamp DEFAULT current_timestamp
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
);
</programlisting>
</para>
<para>
Define two <literal>NOT NULL</> column constraints on the table
<classname>distributors</classname>, one of which is explicitly
given a name:
<programlisting>
CREATE TABLE distributors (
More editing of reference pages.
2003-04-22 12:08:08 +02:00
did integer CONSTRAINT no_null NOT NULL,
name varchar(40) NOT NULL
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
);
</programlisting>
</para>
<para>
Define a unique constraint for the <literal>name</literal> column:
<programlisting>
CREATE TABLE distributors (
More editing of reference pages.
2003-04-22 12:08:08 +02:00
did integer,
name varchar(40) UNIQUE
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
);
</programlisting>
Documentation fixes for FILLFACTOR patch. Minor other editorialization.
2006-07-04 20:07:24 +02:00
The same, specified as a table constraint:
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<programlisting>
CREATE TABLE distributors (
More editing of reference pages.
2003-04-22 12:08:08 +02:00
did integer,
name varchar(40),
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
UNIQUE(name)
);
Tablespace examples for CREATE TABLE/INDEX/SCHEMA/DATABASE as well as some other examples for CREATE DATABASE. Gavin Sherry
2004-07-12 03:22:53 +02:00
</programlisting>
</para>
Documentation fixes for FILLFACTOR patch. Minor other editorialization.
2006-07-04 20:07:24 +02:00
<para>
Create the same table, specifying 70% fill factor for both the table
and its unique index:
<programlisting>
CREATE TABLE distributors (
did integer,
name varchar(40),
UNIQUE(name) WITH (fillfactor=70)
)
WITH (fillfactor=70);
</programlisting>
</para>
Add exclusion constraints, which generalize the concept of uniqueness to support any indexable commutative operator, not just equality. Two rows violate the exclusion constraint if "row1.col OP row2.col" is TRUE for each of the columns in the constraint. Jeff Davis, reviewed by Robert Haas
2009-12-07 06:22:23 +01:00
<para>
Create table <structname>circles</> with an exclusion
constraint that prevents any two circles from overlapping:
<programlisting>
CREATE TABLE circles (
c circle,
Entity-ify a few new uses of literal <, >, and &.
2010-02-27 05:29:44 +01:00
EXCLUDE USING gist (c WITH &amp;&amp;)
Add exclusion constraints, which generalize the concept of uniqueness to support any indexable commutative operator, not just equality. Two rows violate the exclusion constraint if "row1.col OP row2.col" is TRUE for each of the columns in the constraint. Jeff Davis, reviewed by Robert Haas
2009-12-07 06:22:23 +01:00
);
</programlisting>
</para>
Tablespace examples for CREATE TABLE/INDEX/SCHEMA/DATABASE as well as some other examples for CREATE DATABASE. Gavin Sherry
2004-07-12 03:22:53 +02:00
<para>
Create table <structname>cinemas</> in tablespace <structname>diskvol1</>:
<programlisting>
CREATE TABLE cinemas (
Disallow referential integrity actions from being deferred; only the NO ACTION check is deferrable. This seems to be a closer approximation to what the SQL spec says than what we were doing before, and it prevents some anomalous behaviors that are possible now that triggers can fire during the execution of PL functions. Stephan Szabo.
2004-10-21 23:33:59 +02:00
id serial,
name text,
location text
Tablespace examples for CREATE TABLE/INDEX/SCHEMA/DATABASE as well as some other examples for CREATE DATABASE. Gavin Sherry
2004-07-12 03:22:53 +02:00
) TABLESPACE diskvol1;
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
</programlisting>
</para>
Type table feature This adds the CREATE TABLE name OF type command, per SQL standard.
2010-01-29 00:21:13 +01:00
<para>
Create a composite type and a typed table:
<programlisting>
CREATE TYPE employee_type AS (name text, salary numeric);
CREATE TABLE employees OF employee_type (
PRIMARY KEY (name),
salary WITH OPTIONS DEFAULT 1000
);
Implement table partitioning. Table partitioning is like table inheritance and reuses much of the existing infrastructure, but there are some important differences. The parent is called a partitioned table and is always empty; it may not have indexes or non-inherited constraints, since those make no sense for a relation with no data of its own. The children are called partitions and contain all of the actual data. Each partition has an implicit partitioning constraint. Multiple inheritance is not allowed, and partitioning and inheritance can't be mixed. Partitions can't have extra columns and may not allow nulls unless the parent does. Tuples inserted into the parent are automatically routed to the correct partition, so tuple-routing ON INSERT triggers are not needed. Tuple routing isn't yet supported for partitions which are foreign tables, and it doesn't handle updates that cross partition boundaries. Currently, tables can be range-partitioned or list-partitioned. List partitioning is limited to a single column, but range partitioning can involve multiple columns. A partitioning "column" can be an expression. Because table partitioning is less general than table inheritance, it is hoped that it will be easier to reason about properties of partitions, and therefore that this will serve as a better foundation for a variety of possible optimizations, including query planner optimizations. The tuple routing based which this patch does based on the implicit partitioning constraints is an example of this, but it seems likely that many other useful optimizations are also possible. Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat, Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova, Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
</programlisting></para>
<para>
Create a range partitioned table:
<programlisting>
CREATE TABLE measurement (
logdate date not null,
peaktemp int,
unitsales int
) PARTITION BY RANGE (logdate);
Improve CREATE TABLE documentation of partitioning Amit Langote, with corrections by me
2017-02-10 09:59:37 +01:00
</programlisting></para>
<para>
Create a range partitioned table with multiple columns in the partition key:
<programlisting>
CREATE TABLE measurement_year_month (
logdate date not null,
peaktemp int,
unitsales int
) PARTITION BY RANGE (EXTRACT(YEAR FROM logdate), EXTRACT(MONTH FROM logdate));
Implement table partitioning. Table partitioning is like table inheritance and reuses much of the existing infrastructure, but there are some important differences. The parent is called a partitioned table and is always empty; it may not have indexes or non-inherited constraints, since those make no sense for a relation with no data of its own. The children are called partitions and contain all of the actual data. Each partition has an implicit partitioning constraint. Multiple inheritance is not allowed, and partitioning and inheritance can't be mixed. Partitions can't have extra columns and may not allow nulls unless the parent does. Tuples inserted into the parent are automatically routed to the correct partition, so tuple-routing ON INSERT triggers are not needed. Tuple routing isn't yet supported for partitions which are foreign tables, and it doesn't handle updates that cross partition boundaries. Currently, tables can be range-partitioned or list-partitioned. List partitioning is limited to a single column, but range partitioning can involve multiple columns. A partitioning "column" can be an expression. Because table partitioning is less general than table inheritance, it is hoped that it will be easier to reason about properties of partitions, and therefore that this will serve as a better foundation for a variety of possible optimizations, including query planner optimizations. The tuple routing based which this patch does based on the implicit partitioning constraints is an example of this, but it seems likely that many other useful optimizations are also possible. Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat, Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova, Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
</programlisting></para>
<para>
Create a list partitioned table:
<programlisting>
CREATE TABLE cities (
doc: Improve documentation related to table partitioning feature. Commit f0e44751d7175fa3394da2c8f85e3ceb3cdbfe63 implemented table partitioning, but failed to mention the "no row movement" restriction in the documentation. Fix that and a few other issues. Amit Langote, with some additional wordsmithing by me.
2016-12-13 14:18:00 +01:00
city_id bigserial not null,
Implement table partitioning. Table partitioning is like table inheritance and reuses much of the existing infrastructure, but there are some important differences. The parent is called a partitioned table and is always empty; it may not have indexes or non-inherited constraints, since those make no sense for a relation with no data of its own. The children are called partitions and contain all of the actual data. Each partition has an implicit partitioning constraint. Multiple inheritance is not allowed, and partitioning and inheritance can't be mixed. Partitions can't have extra columns and may not allow nulls unless the parent does. Tuples inserted into the parent are automatically routed to the correct partition, so tuple-routing ON INSERT triggers are not needed. Tuple routing isn't yet supported for partitions which are foreign tables, and it doesn't handle updates that cross partition boundaries. Currently, tables can be range-partitioned or list-partitioned. List partitioning is limited to a single column, but range partitioning can involve multiple columns. A partitioning "column" can be an expression. Because table partitioning is less general than table inheritance, it is hoped that it will be easier to reason about properties of partitions, and therefore that this will serve as a better foundation for a variety of possible optimizations, including query planner optimizations. The tuple routing based which this patch does based on the implicit partitioning constraints is an example of this, but it seems likely that many other useful optimizations are also possible. Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat, Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova, Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
name text not null,
doc: Fix typos From: Thom Brown <thom@linux.com>
2017-02-18 00:59:29 +01:00
population bigint
doc: Improve documentation related to table partitioning feature. Commit f0e44751d7175fa3394da2c8f85e3ceb3cdbfe63 implemented table partitioning, but failed to mention the "no row movement" restriction in the documentation. Fix that and a few other issues. Amit Langote, with some additional wordsmithing by me.
2016-12-13 14:18:00 +01:00
) PARTITION BY LIST (left(lower(name), 1));
Implement table partitioning. Table partitioning is like table inheritance and reuses much of the existing infrastructure, but there are some important differences. The parent is called a partitioned table and is always empty; it may not have indexes or non-inherited constraints, since those make no sense for a relation with no data of its own. The children are called partitions and contain all of the actual data. Each partition has an implicit partitioning constraint. Multiple inheritance is not allowed, and partitioning and inheritance can't be mixed. Partitions can't have extra columns and may not allow nulls unless the parent does. Tuples inserted into the parent are automatically routed to the correct partition, so tuple-routing ON INSERT triggers are not needed. Tuple routing isn't yet supported for partitions which are foreign tables, and it doesn't handle updates that cross partition boundaries. Currently, tables can be range-partitioned or list-partitioned. List partitioning is limited to a single column, but range partitioning can involve multiple columns. A partitioning "column" can be an expression. Because table partitioning is less general than table inheritance, it is hoped that it will be easier to reason about properties of partitions, and therefore that this will serve as a better foundation for a variety of possible optimizations, including query planner optimizations. The tuple routing based which this patch does based on the implicit partitioning constraints is an example of this, but it seems likely that many other useful optimizations are also possible. Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat, Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova, Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
</programlisting></para>
<para>
Create partition of a range partitioned table:
<programlisting>
CREATE TABLE measurement_y2016m07
PARTITION OF measurement (
doc: Improve documentation related to table partitioning feature. Commit f0e44751d7175fa3394da2c8f85e3ceb3cdbfe63 implemented table partitioning, but failed to mention the "no row movement" restriction in the documentation. Fix that and a few other issues. Amit Langote, with some additional wordsmithing by me.
2016-12-13 14:18:00 +01:00
unitsales DEFAULT 0
Implement table partitioning. Table partitioning is like table inheritance and reuses much of the existing infrastructure, but there are some important differences. The parent is called a partitioned table and is always empty; it may not have indexes or non-inherited constraints, since those make no sense for a relation with no data of its own. The children are called partitions and contain all of the actual data. Each partition has an implicit partitioning constraint. Multiple inheritance is not allowed, and partitioning and inheritance can't be mixed. Partitions can't have extra columns and may not allow nulls unless the parent does. Tuples inserted into the parent are automatically routed to the correct partition, so tuple-routing ON INSERT triggers are not needed. Tuple routing isn't yet supported for partitions which are foreign tables, and it doesn't handle updates that cross partition boundaries. Currently, tables can be range-partitioned or list-partitioned. List partitioning is limited to a single column, but range partitioning can involve multiple columns. A partitioning "column" can be an expression. Because table partitioning is less general than table inheritance, it is hoped that it will be easier to reason about properties of partitions, and therefore that this will serve as a better foundation for a variety of possible optimizations, including query planner optimizations. The tuple routing based which this patch does based on the implicit partitioning constraints is an example of this, but it seems likely that many other useful optimizations are also possible. Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat, Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova, Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
) FOR VALUES FROM ('2016-07-01') TO ('2016-08-01');
</programlisting></para>
Improve CREATE TABLE documentation of partitioning Amit Langote, with corrections by me
2017-02-10 09:59:37 +01:00
<para>
Create a few partitions of a range partitioned table with multiple
columns in the partition key:
<programlisting>
CREATE TABLE measurement_ym_older
PARTITION OF measurement_year_month
After a MINVALUE/MAXVALUE bound, allow only more of the same. In the old syntax, which used UNBOUNDED, we had a similar restriction, but commit d363d42bb9a4399a0207bd3b371c966e22e06bd3, which changed the syntax, eliminated it. Put it back. Patch by me, reviewed by Dean Rasheed. Discussion: http://postgr.es/m/CA+Tgmobs+pLPC27tS3gOpEAxAffHrq5w509cvkwTf9pF6cWYbg@mail.gmail.com
2017-09-16 03:15:55 +02:00
FOR VALUES FROM (MINVALUE, MINVALUE) TO (2016, 11);
Improve CREATE TABLE documentation of partitioning Amit Langote, with corrections by me
2017-02-10 09:59:37 +01:00
CREATE TABLE measurement_ym_y2016m11
PARTITION OF measurement_year_month
FOR VALUES FROM (2016, 11) TO (2016, 12);
CREATE TABLE measurement_ym_y2016m12
PARTITION OF measurement_year_month
FOR VALUES FROM (2016, 12) TO (2017, 01);
CREATE TABLE measurement_ym_y2017m01
PARTITION OF measurement_year_month
FOR VALUES FROM (2017, 01) TO (2017, 02);
</programlisting></para>
Implement table partitioning. Table partitioning is like table inheritance and reuses much of the existing infrastructure, but there are some important differences. The parent is called a partitioned table and is always empty; it may not have indexes or non-inherited constraints, since those make no sense for a relation with no data of its own. The children are called partitions and contain all of the actual data. Each partition has an implicit partitioning constraint. Multiple inheritance is not allowed, and partitioning and inheritance can't be mixed. Partitions can't have extra columns and may not allow nulls unless the parent does. Tuples inserted into the parent are automatically routed to the correct partition, so tuple-routing ON INSERT triggers are not needed. Tuple routing isn't yet supported for partitions which are foreign tables, and it doesn't handle updates that cross partition boundaries. Currently, tables can be range-partitioned or list-partitioned. List partitioning is limited to a single column, but range partitioning can involve multiple columns. A partitioning "column" can be an expression. Because table partitioning is less general than table inheritance, it is hoped that it will be easier to reason about properties of partitions, and therefore that this will serve as a better foundation for a variety of possible optimizations, including query planner optimizations. The tuple routing based which this patch does based on the implicit partitioning constraints is an example of this, but it seems likely that many other useful optimizations are also possible. Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat, Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova, Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
<para>
Create partition of a list partitioned table:
<programlisting>
doc: Improve documentation related to table partitioning feature. Commit f0e44751d7175fa3394da2c8f85e3ceb3cdbfe63 implemented table partitioning, but failed to mention the "no row movement" restriction in the documentation. Fix that and a few other issues. Amit Langote, with some additional wordsmithing by me.
2016-12-13 14:18:00 +01:00
CREATE TABLE cities_ab
Implement table partitioning. Table partitioning is like table inheritance and reuses much of the existing infrastructure, but there are some important differences. The parent is called a partitioned table and is always empty; it may not have indexes or non-inherited constraints, since those make no sense for a relation with no data of its own. The children are called partitions and contain all of the actual data. Each partition has an implicit partitioning constraint. Multiple inheritance is not allowed, and partitioning and inheritance can't be mixed. Partitions can't have extra columns and may not allow nulls unless the parent does. Tuples inserted into the parent are automatically routed to the correct partition, so tuple-routing ON INSERT triggers are not needed. Tuple routing isn't yet supported for partitions which are foreign tables, and it doesn't handle updates that cross partition boundaries. Currently, tables can be range-partitioned or list-partitioned. List partitioning is limited to a single column, but range partitioning can involve multiple columns. A partitioning "column" can be an expression. Because table partitioning is less general than table inheritance, it is hoped that it will be easier to reason about properties of partitions, and therefore that this will serve as a better foundation for a variety of possible optimizations, including query planner optimizations. The tuple routing based which this patch does based on the implicit partitioning constraints is an example of this, but it seems likely that many other useful optimizations are also possible. Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat, Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova, Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
PARTITION OF cities (
CONSTRAINT city_id_nonzero CHECK (city_id != 0)
doc: Improve documentation related to table partitioning feature. Commit f0e44751d7175fa3394da2c8f85e3ceb3cdbfe63 implemented table partitioning, but failed to mention the "no row movement" restriction in the documentation. Fix that and a few other issues. Amit Langote, with some additional wordsmithing by me.
2016-12-13 14:18:00 +01:00
) FOR VALUES IN ('a', 'b');
Implement table partitioning. Table partitioning is like table inheritance and reuses much of the existing infrastructure, but there are some important differences. The parent is called a partitioned table and is always empty; it may not have indexes or non-inherited constraints, since those make no sense for a relation with no data of its own. The children are called partitions and contain all of the actual data. Each partition has an implicit partitioning constraint. Multiple inheritance is not allowed, and partitioning and inheritance can't be mixed. Partitions can't have extra columns and may not allow nulls unless the parent does. Tuples inserted into the parent are automatically routed to the correct partition, so tuple-routing ON INSERT triggers are not needed. Tuple routing isn't yet supported for partitions which are foreign tables, and it doesn't handle updates that cross partition boundaries. Currently, tables can be range-partitioned or list-partitioned. List partitioning is limited to a single column, but range partitioning can involve multiple columns. A partitioning "column" can be an expression. Because table partitioning is less general than table inheritance, it is hoped that it will be easier to reason about properties of partitions, and therefore that this will serve as a better foundation for a variety of possible optimizations, including query planner optimizations. The tuple routing based which this patch does based on the implicit partitioning constraints is an example of this, but it seems likely that many other useful optimizations are also possible. Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat, Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova, Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
</programlisting></para>
<para>
Create partition of a list partitioned table that is itself further
partitioned and then add a partition to it:
<programlisting>
doc: Improve documentation related to table partitioning feature. Commit f0e44751d7175fa3394da2c8f85e3ceb3cdbfe63 implemented table partitioning, but failed to mention the "no row movement" restriction in the documentation. Fix that and a few other issues. Amit Langote, with some additional wordsmithing by me.
2016-12-13 14:18:00 +01:00
CREATE TABLE cities_ab
Implement table partitioning. Table partitioning is like table inheritance and reuses much of the existing infrastructure, but there are some important differences. The parent is called a partitioned table and is always empty; it may not have indexes or non-inherited constraints, since those make no sense for a relation with no data of its own. The children are called partitions and contain all of the actual data. Each partition has an implicit partitioning constraint. Multiple inheritance is not allowed, and partitioning and inheritance can't be mixed. Partitions can't have extra columns and may not allow nulls unless the parent does. Tuples inserted into the parent are automatically routed to the correct partition, so tuple-routing ON INSERT triggers are not needed. Tuple routing isn't yet supported for partitions which are foreign tables, and it doesn't handle updates that cross partition boundaries. Currently, tables can be range-partitioned or list-partitioned. List partitioning is limited to a single column, but range partitioning can involve multiple columns. A partitioning "column" can be an expression. Because table partitioning is less general than table inheritance, it is hoped that it will be easier to reason about properties of partitions, and therefore that this will serve as a better foundation for a variety of possible optimizations, including query planner optimizations. The tuple routing based which this patch does based on the implicit partitioning constraints is an example of this, but it seems likely that many other useful optimizations are also possible. Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat, Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova, Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
PARTITION OF cities (
CONSTRAINT city_id_nonzero CHECK (city_id != 0)
doc: Improve documentation related to table partitioning feature. Commit f0e44751d7175fa3394da2c8f85e3ceb3cdbfe63 implemented table partitioning, but failed to mention the "no row movement" restriction in the documentation. Fix that and a few other issues. Amit Langote, with some additional wordsmithing by me.
2016-12-13 14:18:00 +01:00
) FOR VALUES IN ('a', 'b') PARTITION BY RANGE (population);
Implement table partitioning. Table partitioning is like table inheritance and reuses much of the existing infrastructure, but there are some important differences. The parent is called a partitioned table and is always empty; it may not have indexes or non-inherited constraints, since those make no sense for a relation with no data of its own. The children are called partitions and contain all of the actual data. Each partition has an implicit partitioning constraint. Multiple inheritance is not allowed, and partitioning and inheritance can't be mixed. Partitions can't have extra columns and may not allow nulls unless the parent does. Tuples inserted into the parent are automatically routed to the correct partition, so tuple-routing ON INSERT triggers are not needed. Tuple routing isn't yet supported for partitions which are foreign tables, and it doesn't handle updates that cross partition boundaries. Currently, tables can be range-partitioned or list-partitioned. List partitioning is limited to a single column, but range partitioning can involve multiple columns. A partitioning "column" can be an expression. Because table partitioning is less general than table inheritance, it is hoped that it will be easier to reason about properties of partitions, and therefore that this will serve as a better foundation for a variety of possible optimizations, including query planner optimizations. The tuple routing based which this patch does based on the implicit partitioning constraints is an example of this, but it seems likely that many other useful optimizations are also possible. Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat, Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova, Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
doc: Improve documentation related to table partitioning feature. Commit f0e44751d7175fa3394da2c8f85e3ceb3cdbfe63 implemented table partitioning, but failed to mention the "no row movement" restriction in the documentation. Fix that and a few other issues. Amit Langote, with some additional wordsmithing by me.
2016-12-13 14:18:00 +01:00
CREATE TABLE cities_ab_10000_to_100000
PARTITION OF cities_ab FOR VALUES FROM (10000) TO (100000);
Fix a whitespace issue with the man pages There is what may actually be a mistake in our markup. The problem is in a situation like <para> <command>FOO</command> is ... there is strictly speaking a line break before "FOO". In the HTML output, this does not appear to be a problem, but in the man page output, this shows up, so you get double blank lines at odd places. So far, we have attempted to work around this with an XSL hack, but that causes other problems, such as creating run-ins in places like <acronym>SQL</acronym> <command>COPY</command> So fix the problem properly by removing the extra whitespace. I only fixed the problems that affect the man page output, not all the places.
2011-08-07 09:49:45 +02:00
</programlisting></para>
Allow a partitioned table to have a default partition. Any tuples that don't route to any other partition will route to the default partition. Jeevan Ladhe, Beena Emerson, Ashutosh Bapat, Rahila Syed, and Robert Haas, with review and testing at various stages by (at least) Rushabh Lathia, Keith Fiske, Amit Langote, Amul Sul, Rajkumar Raghuanshi, Sven Kunze, Kyotaro Horiguchi, Thom Brown, Rafia Sabih, and Dilip Kumar. Discussion: http://postgr.es/m/CAH2L28tbN4SYyhS7YV1YBWcitkqbhSWfQCy0G=apRcC_PEO-bg@mail.gmail.com Discussion: http://postgr.es/m/CAOG9ApEYj34fWMcvBMBQ-YtqR9fTdXhdN82QEKG0SVZ6zeL1xg@mail.gmail.com
2017-09-08 23:28:04 +02:00
<para>
Create a default partition:
<programlisting>
CREATE TABLE cities_partdef
PARTITION OF cities DEFAULT;
</programlisting></para>
Minor updates for release. Split reference pages for CREATE TABLE AS and SELECT INTO to allow psgml (the emacs parser) to handle parsing.
1999-06-14 09:37:05 +02:00
</refsect1>
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<refsect1 id="SQL-CREATETABLE-compatibility">
<title id="SQL-CREATETABLE-compatibility-title">Compatibility</title>
<para>
Make an editorial pass over the reference pages.
2005-11-01 22:09:51 +01:00
The <command>CREATE TABLE</command> command conforms to the
<acronym>SQL</acronym> standard, with exceptions listed below.
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
</para>
<refsect2>
<title>Temporary Tables</title>
Minor updates for release. Split reference pages for CREATE TABLE AS and SELECT INTO to allow psgml (the emacs parser) to handle parsing.
1999-06-14 09:37:05 +02:00
<para>
Clarify description of our deviation from standard for temp tables, per suggestion from Mike Sykes.
2003-04-14 17:24:46 +02:00
Although the syntax of <literal>CREATE TEMPORARY TABLE</literal>
When a TIMESTAMP, TIME, or INTERVAL precision is specified larger than our implementation limits, do not issue an ERROR; instead issue a NOTICE and use the max supported value. Per pgsql-general discussion of 28-Apr, this is needed to allow easy porting from pre-7.3 releases where the limits were higher. Unrelated change in same area: accept GLOBAL TEMP/TEMPORARY as a synonym for TEMPORARY, as per pgsql-hackers discussion of 15-Apr. We previously rejected it, but that was based on a misreading of the spec --- SQL92's GLOBAL temp tables are really closer to what we have than their LOCAL ones.
2003-05-04 02:03:55 +02:00
resembles that of the SQL standard, the effect is not the same. In the
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
standard,
Another try at correctly explaining the difference between Postgres and SQL92 temp tables. Possibly I got it right this time.
2003-04-14 20:08:58 +02:00
temporary tables are defined just once and automatically exist (starting
with empty contents) in every session that needs them.
<productname>PostgreSQL</productname> instead
Clarify description of our deviation from standard for temp tables, per suggestion from Mike Sykes.
2003-04-14 17:24:46 +02:00
requires each session to issue its own <literal>CREATE TEMPORARY
Another try at correctly explaining the difference between Postgres and SQL92 temp tables. Possibly I got it right this time.
2003-04-14 20:08:58 +02:00
TABLE</literal> command for each temporary table to be used. This allows
different sessions to use the same temporary table name for different
More editing of reference pages.
2003-04-22 12:08:08 +02:00
purposes, whereas the standard's approach constrains all instances of a
Another try at correctly explaining the difference between Postgres and SQL92 temp tables. Possibly I got it right this time.
2003-04-14 20:08:58 +02:00
given temporary table name to have the same table structure.
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
</para>
More editing of reference pages.
2003-04-22 12:08:08 +02:00
<para>
When a TIMESTAMP, TIME, or INTERVAL precision is specified larger than our implementation limits, do not issue an ERROR; instead issue a NOTICE and use the max supported value. Per pgsql-general discussion of 28-Apr, this is needed to allow easy porting from pre-7.3 releases where the limits were higher. Unrelated change in same area: accept GLOBAL TEMP/TEMPORARY as a synonym for TEMPORARY, as per pgsql-hackers discussion of 15-Apr. We previously rejected it, but that was based on a misreading of the spec --- SQL92's GLOBAL temp tables are really closer to what we have than their LOCAL ones.
2003-05-04 02:03:55 +02:00
The standard's definition of the behavior of temporary tables is
More editing of reference pages.
2003-04-22 12:08:08 +02:00
widely ignored. <productname>PostgreSQL</productname>'s behavior
on this point is similar to that of several other SQL databases.
</para>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
Another try at correctly explaining the difference between Postgres and SQL92 temp tables. Possibly I got it right this time.
2003-04-14 20:08:58 +02:00
<para>
Deprecate use of GLOBAL and LOCAL in temp table creation. Aside from adjusting the documentation to say that these are deprecated, we now report a warning (not an error) for use of GLOBAL, since it seems fairly likely that we might change that to request SQL-spec-compliant temp table behavior in the foreseeable future. Although our handling of LOCAL is equally nonstandard, there is no evident interest in ever implementing SQL modules, and furthermore some other products interpret LOCAL as behaving the same way we do. So no expectation of change and no warning for LOCAL; but it still seems a good idea to deprecate writing it. Noah Misch
2012-06-13 23:48:42 +02:00
The SQL standard also distinguishes between global and local temporary
Fix description of SQL-standard meaning of CREATE LOCAL TEMP TABLE. I had this slightly wrong, as noted by Noah Misch.
2012-06-14 00:47:53 +02:00
tables, where a local temporary table has a separate set of contents for
each SQL module within each session, though its definition is still shared
across sessions. Since <productname>PostgreSQL</productname> does not
support SQL modules, this distinction is not relevant in
<productname>PostgreSQL</productname>.
Deprecate use of GLOBAL and LOCAL in temp table creation. Aside from adjusting the documentation to say that these are deprecated, we now report a warning (not an error) for use of GLOBAL, since it seems fairly likely that we might change that to request SQL-spec-compliant temp table behavior in the foreseeable future. Although our handling of LOCAL is equally nonstandard, there is no evident interest in ever implementing SQL modules, and furthermore some other products interpret LOCAL as behaving the same way we do. So no expectation of change and no warning for LOCAL; but it still seems a good idea to deprecate writing it. Noah Misch
2012-06-13 23:48:42 +02:00
</para>
<para>
When a TIMESTAMP, TIME, or INTERVAL precision is specified larger than our implementation limits, do not issue an ERROR; instead issue a NOTICE and use the max supported value. Per pgsql-general discussion of 28-Apr, this is needed to allow easy porting from pre-7.3 releases where the limits were higher. Unrelated change in same area: accept GLOBAL TEMP/TEMPORARY as a synonym for TEMPORARY, as per pgsql-hackers discussion of 15-Apr. We previously rejected it, but that was based on a misreading of the spec --- SQL92's GLOBAL temp tables are really closer to what we have than their LOCAL ones.
2003-05-04 02:03:55 +02:00
For compatibility's sake, <productname>PostgreSQL</productname> will
accept the <literal>GLOBAL</literal> and <literal>LOCAL</literal> keywords
Deprecate use of GLOBAL and LOCAL in temp table creation. Aside from adjusting the documentation to say that these are deprecated, we now report a warning (not an error) for use of GLOBAL, since it seems fairly likely that we might change that to request SQL-spec-compliant temp table behavior in the foreseeable future. Although our handling of LOCAL is equally nonstandard, there is no evident interest in ever implementing SQL modules, and furthermore some other products interpret LOCAL as behaving the same way we do. So no expectation of change and no warning for LOCAL; but it still seems a good idea to deprecate writing it. Noah Misch
2012-06-13 23:48:42 +02:00
in a temporary table declaration, but they currently have no effect.
Use of these keywords is discouraged, since future versions of
<productname>PostgreSQL</productname> might adopt a more
standard-compliant interpretation of their meaning.
Another try at correctly explaining the difference between Postgres and SQL92 temp tables. Possibly I got it right this time.
2003-04-14 20:08:58 +02:00
</para>
Clarify description of our deviation from standard for temp tables, per suggestion from Mike Sykes.
2003-04-14 17:24:46 +02:00
<para>
Minor copy-editing.
2003-04-14 17:40:02 +02:00
The <literal>ON COMMIT</literal> clause for temporary tables
More editing of reference pages.
2003-04-22 12:08:08 +02:00
also resembles the SQL standard, but has some differences.
If the <literal>ON COMMIT</> clause is omitted, SQL specifies that the
Clarify description of our deviation from standard for temp tables, per suggestion from Mike Sykes.
2003-04-14 17:24:46 +02:00
default behavior is <literal>ON COMMIT DELETE ROWS</>. However, the
default behavior in <productname>PostgreSQL</productname> is
<literal>ON COMMIT PRESERVE ROWS</literal>. The <literal>ON COMMIT
More editing of reference pages.
2003-04-22 12:08:08 +02:00
DROP</literal> option does not exist in SQL.
First version of files from Oliver Elphick.
1998-07-14 05:47:34 +02:00
</para>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
</refsect2>
Support deferrable uniqueness constraints. The current implementation fires an AFTER ROW trigger for each tuple that looks like it might be non-unique according to the index contents at the time of insertion. This works well as long as there aren't many conflicts, but won't scale to massive unique-key reassignments. Improving that case is a TODO item. Dean Rasheed
2009-07-29 22:56:21 +02:00
<refsect2>
<title>Non-deferred Uniqueness Constraints</title>
<para>
When a <literal>UNIQUE</> or <literal>PRIMARY KEY</> constraint is
not deferrable, <productname>PostgreSQL</productname> checks for
uniqueness immediately whenever a row is inserted or modified.
The SQL standard says that uniqueness should be enforced only at
the end of the statement; this makes a difference when, for example,
a single command updates multiple key values. To obtain
standard-compliant behavior, declare the constraint as
<literal>DEFERRABLE</> but not deferred (i.e., <literal>INITIALLY
IMMEDIATE</>). Be aware that this can be significantly slower than
immediate uniqueness checking.
</para>
</refsect2>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<refsect2>
More editing of reference pages.
2003-04-22 12:08:08 +02:00
<title>Column Check Constraints</title>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
First version of files from Oliver Elphick.
1998-07-14 05:47:34 +02:00
<para>
More editing of reference pages.
2003-04-22 12:08:08 +02:00
The SQL standard says that <literal>CHECK</> column constraints
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
can only refer to the column they apply to; only <literal>CHECK</>
table constraints can refer to multiple columns.
More editing of reference pages.
2003-04-22 12:08:08 +02:00
<productname>PostgreSQL</productname> does not enforce this
restriction; it treats column and table check constraints alike.
First version of files from Oliver Elphick.
1998-07-14 05:47:34 +02:00
</para>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
</refsect2>
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
Add exclusion constraints, which generalize the concept of uniqueness to support any indexable commutative operator, not just equality. Two rows violate the exclusion constraint if "row1.col OP row2.col" is TRUE for each of the columns in the constraint. Jeff Davis, reviewed by Robert Haas
2009-12-07 06:22:23 +01:00
<refsect2>
<title><literal>EXCLUDE</literal> Constraint</title>
<para>
The <literal>EXCLUDE</> constraint type is a
<productname>PostgreSQL</productname> extension.
</para>
</refsect2>
More editing of reference pages.
2003-04-22 12:08:08 +02:00
<refsect2>
<title><literal>NULL</literal> <quote>Constraint</quote></title>
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<para>
More editing of reference pages.
2003-04-22 12:08:08 +02:00
The <literal>NULL</> <quote>constraint</quote> (actually a
non-constraint) is a <productname>PostgreSQL</productname>
extension to the SQL standard that is included for compatibility with some
other database systems (and for symmetry with the <literal>NOT
NULL</literal> constraint). Since it is the default for any
column, its presence is simply noise.
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
</para>
</refsect2>
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<refsect2>
<title>Inheritance</title>
Fix markup for docbook2man man page generation. No big deal; fixed lots of other markup at the same time. Bigest change: make sure there is no whitespace in front of <term> contents. This will probably help the other output types too.
1999-07-06 19:16:42 +02:00
<para>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
Multiple inheritance via the <literal>INHERITS</literal> clause is
Update of conformance information to SQL:2003 by Troels Arvin, Simon Riggs, Elein Mustain Make spelling of SQL standard names uniform.
2004-11-27 22:27:08 +01:00
a <productname>PostgreSQL</productname> language extension.
Make an editorial pass over the reference pages.
2005-11-01 22:09:51 +01:00
SQL:1999 and later define single inheritance using a
different syntax and different semantics. SQL:1999-style
Update of conformance information to SQL:2003 by Troels Arvin, Simon Riggs, Elein Mustain Make spelling of SQL standard names uniform.
2004-11-27 22:27:08 +01:00
inheritance is not yet supported by
<productname>PostgreSQL</productname>.
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
</para>
</refsect2>
First version of files from Oliver Elphick.
1998-07-14 05:47:34 +02:00
Document that zero-column tables are allowed (and non-standard).
2002-12-16 20:08:25 +01:00
<refsect2>
Properly capitalize hyphenated words in documentation titles.
2011-02-01 23:00:26 +01:00
<title>Zero-column Tables</title>
Document that zero-column tables are allowed (and non-standard).
2002-12-16 20:08:25 +01:00
<para>
<productname>PostgreSQL</productname> allows a table of no columns
to be created (for example, <literal>CREATE TABLE foo();</>). This
is an extension from the SQL standard, which does not allow zero-column
tables. Zero-column tables are not in themselves very useful, but
disallowing them creates odd special cases for <command>ALTER TABLE
DROP COLUMN</>, so it seems cleaner to ignore this spec restriction.
</para>
</refsect2>
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
Identity columns This is the SQL standard-conforming variant of PostgreSQL's serial columns. It fixes a few usability issues that serial columns have: - CREATE TABLE / LIKE copies default but refers to same sequence - cannot add/drop serialness with ALTER TABLE - dropping default does not drop sequence - need to grant separate privileges to sequence - other slight weirdnesses because serial is some kind of special macro Reviewed-by: Vitaly Burovoy <vitaly.burovoy@gmail.com>
2017-04-06 14:33:16 +02:00
<refsect2>
<title>Multiple Identity Columns</title>
<para>
<productname>PostgreSQL</productname> allows a table to have more than one
identity column. The standard specifies that a table can have at most one
identity column. This is relaxed mainly to give more flexibility for
doing schema changes or migrations. Note that
the <command>INSERT</command> command supports only one override clause
that applies to the entire statement, so having multiple identity columns
with different behaviors is not well supported.
</para>
</refsect2>
Improve documentation about CREATE TABLE ... LIKE. The docs failed to explain that LIKE INCLUDING INDEXES would not preserve the names of indexes and associated constraints. Also, it wasn't mentioned that EXCLUDE constraints would be copied by this option. The latter oversight seems enough of a documentation bug to justify back-patching. In passing, do some minor copy-editing in the same area, and add an entry for LIKE under "Compatibility", since it's not exactly a faithful implementation of the standard's feature. Discussion: <20160728151154.AABE64016B@smtp.hushmail.com>
2016-07-28 19:26:58 +02:00
<refsect2>
<title><literal>LIKE</> Clause</title>
<para>
While a <literal>LIKE</> clause exists in the SQL standard, many of the
options that <productname>PostgreSQL</productname> accepts for it are not
in the standard, and some of the standard's options are not implemented
by <productname>PostgreSQL</productname>.
</para>
</refsect2>
Documentation fixes for FILLFACTOR patch. Minor other editorialization.
2006-07-04 20:07:24 +02:00
<refsect2>
Properly capitalize documentation headings; some only had initial-word capitalization.
2011-01-29 19:00:18 +01:00
<title><literal>WITH</> Clause</title>
Documentation fixes for FILLFACTOR patch. Minor other editorialization.
2006-07-04 20:07:24 +02:00
<para>
The <literal>WITH</> clause is a <productname>PostgreSQL</productname>
extension; neither storage parameters nor OIDs are in the standard.
</para>
</refsect2>
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
<refsect2>
Spell checker run
2004-12-13 19:05:10 +01:00
<title>Tablespaces</title>
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
<para>
The <productname>PostgreSQL</productname> concept of tablespaces is not
Spell checker run
2004-12-13 19:05:10 +01:00
part of the standard. Hence, the clauses <literal>TABLESPACE</literal>
and <literal>USING INDEX TABLESPACE</literal> are extensions.
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
</para>
</refsect2>
Type table feature This adds the CREATE TABLE name OF type command, per SQL standard.
2010-01-29 00:21:13 +01:00
<refsect2>
<title>Typed Tables</title>
<para>
Typed tables implement a subset of the SQL standard. According to
the standard, a typed table has columns corresponding to the
underlying composite type as well as one other column that is
the <quote>self-referencing column</quote>. PostgreSQL does not
support these self-referencing columns explicitly, but the same
effect can be had using the OID feature.
</para>
</refsect2>
Improve CREATE TABLE documentation of partitioning Amit Langote, with corrections by me
2017-02-10 09:59:37 +01:00
<refsect2>
<title><literal>PARTITION BY</> Clause</title>
<para>
The <literal>PARTITION BY</> clause is a
<productname>PostgreSQL</productname> extension.
</para>
</refsect2>
<refsect2>
<title><literal>PARTITION OF</> Clause</title>
<para>
The <literal>PARTITION OF</> clause is a
<productname>PostgreSQL</productname> extension.
</para>
</refsect2>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
</refsect1>
Remove not-really-standard implementation of CREATE TABLE's UNDER clause, and revert documentation to describe the existing INHERITS clause instead, per recent discussion in pghackers. Also fix implementation of SQL_inheritance SET variable: it is not cool to look at this var during the initial parsing phase, only during parse_analyze(). See recent bug report concerning misinterpretation of date constants just after a SET TIMEZONE command. gram.y really has to be an invariant transformation of the query string to a raw parsetree; anything that can vary with time must be done during parse analysis.
2001-01-05 07:34:23 +01:00
Make OIDs optional, per discussions in pghackers. WITH OIDS is still the default, but OIDS are removed from many system catalogs that don't need them. Some interesting side effects: TOAST pointers are 20 bytes not 32 now; pg_description has a three-column key instead of one. Bugs fixed in passing: BINARY cursors work again; pg_class.relhaspkey has some usefulness; pg_dump dumps comments on indexes, rules, and triggers in a valid order. initdb forced.
2001-08-10 20:57:42 +02:00
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
<refsect1>
<title>See Also</title>
<simplelist type="inline">
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02:00
<member><xref linkend="sql-altertable"></member>
<member><xref linkend="sql-droptable"></member>
doc: Add link to CREATE TABLE AS on CREATE TABLE reference page Karl O. Pinc
2012-11-13 04:22:47 +01:00
<member><xref linkend="sql-createtableas"></member>
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02:00
<member><xref linkend="sql-createtablespace"></member>
<member><xref linkend="sql-createtype"></member>
Make the CREATE TABLE ref page more readable and update some information.
2001-10-22 20:14:47 +02:00
</simplelist>
First version of files from Oliver Elphick.
1998-07-14 05:47:34 +02:00
</refsect1>
</refentry>