diff --git a/doc/src/sgml/ref/create_table.sgml b/doc/src/sgml/ref/create_table.sgml
index 06e6392f737..bf2ad64d66e 100644
--- a/doc/src/sgml/ref/create_table.sgml
+++ b/doc/src/sgml/ref/create_table.sgml
@@ -329,26 +329,33 @@ CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } | UNLOGGED ] TABLE [ IF NOT EXI
       table.
      </para>
      <para>
-      Default expressions for the copied column definitions will only be
-      copied if <literal>INCLUDING DEFAULTS</literal> is specified.
-      Defaults that call database-modification functions, like
-      <function>nextval</>, create a linkage between the original and
-      new tables.  The
+      Default expressions for the copied column definitions will be copied
+      only if <literal>INCLUDING DEFAULTS</literal> is specified.  The
       default behavior is to exclude default expressions, resulting in the
       copied columns in the new table having null defaults.
+      Note that copying defaults that call database-modification functions,
+      such as <function>nextval</>, may create a functional linkage between
+      the original and new tables.
      </para>
      <para>
       Not-null constraints are always copied to the new table.
       <literal>CHECK</literal> constraints will be copied only if
       <literal>INCLUDING CONSTRAINTS</literal> is specified.
-      Indexes, <literal>PRIMARY KEY</>, and <literal>UNIQUE</> constraints
-      on the original table will be created on the new table only if the
-      <literal>INCLUDING INDEXES</literal> clause is specified.
       No distinction is made between column constraints and table
       constraints.
      </para>
-     <para><literal>STORAGE</> settings for the copied column definitions will only
-      be copied if <literal>INCLUDING STORAGE</literal> is specified.  The
+     <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
       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
@@ -356,24 +363,26 @@ CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } | UNLOGGED ] TABLE [ IF NOT EXI
      </para>
      <para>
       Comments for the copied columns, constraints, and indexes
-      will only be copied if <literal>INCLUDING COMMENTS</literal>
+      will be copied only if <literal>INCLUDING COMMENTS</literal>
       is specified. The default behavior is to exclude comments, resulting in
       the copied columns and constraints in the new table having no comments.
      </para>
-     <para><literal>INCLUDING ALL</literal> is an abbreviated form of
+     <para>
+      <literal>INCLUDING ALL</literal> is an abbreviated form of
       <literal>INCLUDING DEFAULTS INCLUDING CONSTRAINTS INCLUDING INDEXES INCLUDING STORAGE INCLUDING COMMENTS</literal>.
      </para>
      <para>
-      Note also that unlike <literal>INHERITS</literal>, columns and
+      Note that unlike <literal>INHERITS</literal>, columns and
       constraints copied by <literal>LIKE</> are not merged with similarly
       named columns and constraints.
       If the same name is specified explicitly or in another
       <literal>LIKE</literal> clause, an error is signaled.
      </para>
      <para>
-      The <literal>LIKE</literal> clause can also be used to copy columns from
-      views, foreign tables, or composite types.  Inapplicable options (e.g., <literal>INCLUDING
-      INDEXES</literal> from a view) are ignored.
+      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.
      </para>
     </listitem>
    </varlistentry>
@@ -1499,6 +1508,17 @@ CREATE TABLE employees OF employee_type (
    </para>
   </refsect2>
 
+  <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>
+
   <refsect2>
    <title><literal>WITH</> Clause</title>
 
diff --git a/src/backend/parser/parse_utilcmd.c b/src/backend/parser/parse_utilcmd.c
index 6313087174d..e98fad051e4 100644
--- a/src/backend/parser/parse_utilcmd.c
+++ b/src/backend/parser/parse_utilcmd.c
@@ -1143,7 +1143,9 @@ generateClonedIndexStmt(CreateStmtContext *cxt, Relation source_idx,
 
 	/*
 	 * We don't try to preserve the name of the source index; instead, just
-	 * let DefineIndex() choose a reasonable name.
+	 * let DefineIndex() choose a reasonable name.  (If we tried to preserve
+	 * the name, we'd get duplicate-relation-name failures unless the source
+	 * table was in a different schema.)
 	 */
 	index->idxname = NULL;