Re: docs: clarify ALTER TABLE behavior on partitioned tables - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: docs: clarify ALTER TABLE behavior on partitioned tables
Date
Msg-id CAKFQuwbQ=L8w8jEaB8_gW-RrNv2_V-VrFYBump7__z-vh-QJWw@mail.gmail.com
Whole thread Raw
In response to Re: docs: clarify ALTER TABLE behavior on partitioned tables  (Chao Li <li.evan.chao@gmail.com>)
List pgsql-hackers
diff --git a/doc/src/sgml/ref/alter_table.sgml b/doc/src/sgml/ref/alter_table.sgml
index 8577e2cdcdd..188f8f3e04b 100644
--- a/doc/src/sgml/ref/alter_table.sgml
+++ b/doc/src/sgml/ref/alter_table.sgml
@@ -746,11 +746,8 @@ WITH ( MODULUS <replaceable class="parameter">numeric_literal</replaceable>, REM
      </para>
      <para>
       When this command is applied to a partitioned table, the states of
-      corresponding clone triggers in existing partitions are updated too,
-      unless <literal>ONLY</literal> is specified. Triggers in partitions
-      created afterwards inherit the trigger state from the partitioned
-      table, while individual partitions may configure trigger states
-      independently.
+      corresponding clone triggers are updated too, unless <literal>ONLY</literal>
+      is specified.
      </para>
      <para>
       This command acquires a <literal>SHARE ROW EXCLUSIVE</literal> lock.

"existing partitions" is implied here; and the rest is material for create table or implied by the optional ONLY (as we rely upon elsewhere):
<para>
For partitioned tables, this action applies to the partitioned table
and all of its partitions unless <literal>ONLY</literal> is specified.
</para>

@@ -882,14 +879,11 @@ WITH ( MODULUS <replaceable class="parameter">numeric_literal</replaceable>, REM
       See <xref linkend="tableam"/> for more information.
      </para>
      <para>
-      When applied to a partitioned table, there is no data to rewrite.
-      Partitions created afterwards will use the access method specified
-      on the partitioned table, if any, unless overridden by a
-      <literal>USING</literal> clause; otherwise they default to
-      <varname>default_table_access_method</varname>. Specifying
-      <literal>DEFAULT</literal> removes a previously set access method,
-      causing future partitions to use
-      <varname>default_table_access_method</varname>.
+      When applied to a partitioned table, there is no data to rewrite,
+      only the default for newly created partitions is changed.
+      Specifying <literal>DEFAULT</literal> removes a previously set access method,
+      causing future partitions to use <varname>default_table_access_method</varname>.
+      Individual partitions are affected just like any other regular table.
      </para>
     </listitem>
    </varlistentry>

The wording of 'changes the default' adequately condenses the existing wording.  I'm 50/50 on removing mention of default_table_access_method.


@@ -902,10 +896,8 @@ WITH ( MODULUS <replaceable class="parameter">numeric_literal</replaceable>, REM
       moves the data file(s) associated with the table to the new tablespace.
       Indexes on the table, if any, are not moved; but they can be moved
       separately with additional <literal>SET TABLESPACE</literal> commands.
-      When applied to a partitioned table, no data is moved. Existing
-      partitions are not affected, but partitions created afterwards with
-      <command>CREATE TABLE PARTITION OF</command> will use the specified
-      tablespace unless overridden by a <literal>TABLESPACE</literal> clause.
+      When applied to a partitioned table, no data is moved, only the default
+      for newly created partitions is changed.
      </para>
      <para>
       All tables in the current database in a tablespace can be moved by using

Again, 'default' can carry a lot of implied meaning here.

@@ -984,7 +976,7 @@ WITH ( MODULUS <replaceable class="parameter">numeric_literal</replaceable>, REM
      </para>
      <para>
       When applied to a partitioned table, this form is accepted but has no
-      effect.  It can be used on individual partitions, where it
+      practical effect.  It can be used on individual partitions, where it
       behaves as for a regular table.
      </para>
     </listitem>

I don't quite like saying 'no effect' since the command does function; and explaining why it is useless seemed a bit much, so just added the word 'practical' and left it to the reader to infer that the lack of storage and inheritance makes any such property on the partitioned table itself useless.

diff --git a/doc/src/sgml/ref/create_table.sgml b/doc/src/sgml/ref/create_table.sgml
index 780e4f0799f..835f609e2a6 100644
--- a/doc/src/sgml/ref/create_table.sgml
+++ b/doc/src/sgml/ref/create_table.sgml
@@ -635,9 +635,9 @@ WITH ( MODULUS <replaceable class="parameter">numeric_literal</replaceable>, REM
 
      <para>
       When a new partition is created, it generally inherits the current
-      definition-level settings of the parent partitioned table. However,
+      definition-level properties of the parent partitioned table. However,
       some table properties are not inherited automatically. In particular,
-      settings related to ownership, schema, replica identity, row-level
+      properties related to ownership, schema, replica identity, row-level
       security configuration, per-attribute statistics targets, and
       per-attribute options are not inherited unless explicitly specified
       for the partition.




diff --git a/doc/src/sgml/ref/create_table.sgml b/doc/src/sgml/ref/create_table.sgml
index 780e4f0799f..835f609e2a6 100644
--- a/doc/src/sgml/ref/create_table.sgml
+++ b/doc/src/sgml/ref/create_table.sgml
@@ -635,9 +635,9 @@ WITH ( MODULUS <replaceable class="parameter">numeric_literal</replaceable>, REM
 
      <para>
       When a new partition is created, it generally inherits the current
-      definition-level settings of the parent partitioned table. However,
+      definition-level properties of the parent partitioned table. However,
       some table properties are not inherited automatically. In particular,
-      settings related to ownership, schema, replica identity, row-level
+      properties related to ownership, schema, replica identity, row-level
       security configuration, per-attribute statistics targets, and
       per-attribute options are not inherited unless explicitly specified
       for the partition.

Dislike the word "setting" here as it clashes with GUC.  Was going to use "attribute" but its used for column.  Settled on "property".  "Definition-level" seems redundant, consider removing it.

Attached patch as text.

David J.
Attachment

pgsql-hackers by date:

Previous
From: "cca5507"
Date:
Subject: Re: [BUG] Incorrect historic snapshot may be serialized to disk during fast-forwarding
Next
From: Eric Ridge
Date:
Subject: Re: Fwd: pg18 bug? SELECT query doesn't work