diff options
| -rw-r--r-- | doc/src/sgml/ddl.sgml | 21 | ||||
| -rw-r--r-- | doc/src/sgml/ref/create_foreign_table.sgml | 18 | ||||
| -rw-r--r-- | doc/src/sgml/ref/update.sgml | 31 |
3 files changed, 42 insertions, 28 deletions
diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml index 4c1d2f607bb..110f6b46570 100644 --- a/doc/src/sgml/ddl.sgml +++ b/doc/src/sgml/ddl.sgml @@ -3858,27 +3858,6 @@ ALTER TABLE measurement ATTACH PARTITION measurement_y2008m02 <listitem> <para> - When an <command>UPDATE</command> causes a row to move from one - partition to another, there is a chance that another concurrent - <command>UPDATE</command> or <command>DELETE</command> will get a - serialization failure error. Suppose session 1 is performing an - <command>UPDATE</command> on a partition key, and meanwhile a concurrent - session 2 for which this row is visible performs an - <command>UPDATE</command> or <command>DELETE</command> operation on this - row. In such case, session 2's <command>UPDATE</command> or - <command>DELETE</command>, will detect the row movement and raise a - serialization failure error (which always returns with an SQLSTATE code - '40001'). Applications may wish to retry the transaction if this - occurs. In the usual case where the table is not partitioned, or where - there is no row movement, session 2 would have identified the newly - updated row and carried out the - <command>UPDATE</command>/<command>DELETE</command> on this new row - version. - </para> - </listitem> - - <listitem> - <para> <literal>BEFORE ROW</literal> triggers, if necessary, must be defined on individual partitions, not the partitioned table. </para> diff --git a/doc/src/sgml/ref/create_foreign_table.sgml b/doc/src/sgml/ref/create_foreign_table.sgml index 37a45b26dbc..19eb5341e7d 100644 --- a/doc/src/sgml/ref/create_foreign_table.sgml +++ b/doc/src/sgml/ref/create_foreign_table.sgml @@ -161,6 +161,18 @@ CHECK ( <replaceable class="parameter">expression</replaceable> ) [ NO INHERIT ] </varlistentry> <varlistentry> + <term><literal>PARTITION OF <replaceable>parent_table</replaceable> FOR VALUES <replaceable class="parameter">partition_bound_spec</replaceable></literal></term> + <listitem> + <para> + This form can be used to create the foreign table as partition of + the given parent table with specified partition bound values. + See the similar form of + <xref linkend="sql-createtable"/> for more details. + </para> + </listitem> + </varlistentry> + + <varlistentry> <term><literal>CONSTRAINT <replaceable class="parameter">constraint_name</replaceable></literal></term> <listitem> <para> @@ -308,6 +320,12 @@ CHECK ( <replaceable class="parameter">expression</replaceable> ) [ NO INHERIT ] responsibility to ensure that the constraint definition matches reality. </para> + + <para> + While rows can be moved from local partitions to a foreign-table partition + (provided the foreign data wrapper supports tuple routing), they cannot be + moved from a foreign-table partition to another partition. + </para> </refsect1> <refsect1 id="sql-createforeigntable-examples"> diff --git a/doc/src/sgml/ref/update.sgml b/doc/src/sgml/ref/update.sgml index 77430a586cb..f58dcd8877b 100644 --- a/doc/src/sgml/ref/update.sgml +++ b/doc/src/sgml/ref/update.sgml @@ -287,13 +287,30 @@ UPDATE <replaceable class="parameter">count</replaceable> row satisfies its partition constraint, then the row is moved to that partition. If there is no such partition, an error will occur. Behind the scenes, the row movement is actually a <command>DELETE</command> and - <command>INSERT</command> operation. However, there is a possibility that a - concurrent <command>UPDATE</command> or <command>DELETE</command> on the - same row may miss this row. For details see the section - <xref linkend="ddl-partitioning-declarative-limitations"/>. - Currently, rows cannot be moved from a partition that is a - foreign table to some other partition, but they can be moved into a foreign - table if the foreign data wrapper supports it. + <command>INSERT</command> operation. + </para> + + <para> + There is a possibility that a concurrent <command>UPDATE</command> or + <command>DELETE</command> on the row being moved will get a serialization + failure error. Suppose session 1 is performing an <command>UPDATE</command> + on a partition key, and meanwhile a concurrent session 2 for which this + row is visible performs an <command>UPDATE</command> or + <command>DELETE</command> operation on this row. In such case, + session 2's <command>UPDATE</command> or <command>DELETE</command> will + detect the row movement and raise a serialization failure error (which + always returns with an SQLSTATE code '40001'). Applications may wish to + retry the transaction if this occurs. In the usual case where the table + is not partitioned, or where there is no row movement, session 2 would + have identified the newly updated row and carried out the + <command>UPDATE</command>/<command>DELETE</command> on this new row + version. + </para> + + <para> + Note that while rows can be moved from local partitions to a foreign-table + partition (provided the foreign data wrapper supports tuple routing), they + cannot be moved from a foreign-table partition to another partition. </para> </refsect1> |