Re: clean up docs for v12 - Mailing list pgsql-hackers

Hi,

On 2019/05/21 7:59, Andres Freund wrote:
> On 2019-05-20 13:20:01 -0500, Justin Pryzby wrote:
>> @@ -3052,7 +3052,7 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l
>>         simplifies <command>ATTACH/DETACH PARTITION</command> operations:
>>         the partition dependencies need only be added or removed.
>>         Example: a child partitioned index is made partition-dependent
>> -       on both the partition table it is on and the parent partitioned
>> +       on both the table partition and the parent partitioned
>>         index, so that it goes away if either of those is dropped, but
>>         not otherwise.  The dependency on the parent index is primary,
>>         so that if the user tries to drop the child partitioned index,
> 
>> @@ -3115,7 +3115,7 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l
>>     Note that it's quite possible for two objects to be linked by more than
>>     one <structname>pg_depend</structname> entry.  For example, a child
>>     partitioned index would have both a partition-type dependency on its
>> -   associated partition table, and an auto dependency on each column of
>> +   associated table partition, and an auto dependency on each column of
>>     that table that it indexes.  This sort of situation expresses the union
>>     of multiple dependency semantics.  A dependent object can be dropped
>>     without <literal>CASCADE</literal> if any of its dependencies satisfies
> 
> Hm, that's not an improvement from my POV? The version before isn't great either,
> but it seems to improve this'd require a somewhat bigger hammer.

The original "partition table" is meant as "table that is a partition", so
not wrong as such, though  I agree about the bigger hammer part,
especially seeing "a child partitioned index" in both the sentences that
Justin's patch touches, which should really be "an index partition".  So
the two sentences could be modified as follows, including Justin's change
for consistency of the use of "partition":

@@ -3051,13 +3051,12 @@ SCRAM-SHA-256$<replaceable><iteration
count></replaceable>:<replaceable>&l
        instead of, any dependencies the object would normally have.  This
        simplifies <command>ATTACH/DETACH PARTITION</command> operations:
        the partition dependencies need only be added or removed.
-       Example: a child partitioned index is made partition-dependent
-       on both the partition table it is on and the parent partitioned
-       index, so that it goes away if either of those is dropped, but
-       not otherwise.  The dependency on the parent index is primary,
-       so that if the user tries to drop the child partitioned index,
-       the error message will suggest dropping the parent index instead
-       (not the table).
+       Example: an index partition is made partition-dependent on both the
+       table partition it is on and the parent partitioned index, so that it
+       goes away if either of those is dropped, but not otherwise.
+       The dependency on the parent index is primary, so that if the user
+       tries to drop the index partition, the error will suggest dropping the
+       parent index instead (not the table).
       </para>
      </listitem>
     </varlistentry>
@@ -3113,10 +3112,10 @@ SCRAM-SHA-256$<replaceable><iteration
count></replaceable>:<replaceable>&l

   <para>
    Note that it's quite possible for two objects to be linked by more than
-   one <structname>pg_depend</structname> entry.  For example, a child
-   partitioned index would have both a partition-type dependency on its
-   associated partition table, and an auto dependency on each column of
-   that table that it indexes.  This sort of situation expresses the union
+   one <structname>pg_depend</structname> entry.  For example, an index
+   partition would have both a partition-type dependency on its assosiated
+   table partition, and an auto dependency on each column of that table that
+   it indexes.  This sort of situation expresses the union
    of multiple dependency semantics.  A dependent object can be dropped
    without <literal>CASCADE</literal> if any of its dependencies satisfies
    its condition for automatic dropping.  Conversely, all the

Thanks,
Amit