publisher.
          </para>
         </note>

         <para>
          See <xref linkend="logical-replication-gencols"/> for more details about
          logical replication of generated columns.
         </para>
        </listitem>
       </varlistentry>

       <varlistentry id="sql-createpublication-params-with-publish-via-partition-root">
        <term><literal>publish_via_partition_root</literal> (<type>boolean</type>)</term>
        <listitem>
         <para>
          This parameter determines whether changes in a partitioned table (or
          on its partitions) contained in the publication will be published
          using the identity and schema of the partitioned table rather than
          that of the individual partitions that are actually changed; the
          latter is the default.  Enabling this allows the changes to be
          replicated into a non-partitioned table or a partitioned table
          consisting of a different set of partitions.
         </para>

         <para>
          There can be a case where a subscription combines multiple
          publications. If a partitioned table is published by any
          subscribed publications which set
          <literal>publish_via_partition_root = true</literal>, changes on this
          partitioned table (or on its partitions) will be published using
          the identity and schema of this partitioned table rather than
          that of the individual partitions.
         </para>

         <para>
          This parameter also affects how row filters and column lists are
          chosen for partitions; see below for details.
         </para>

         <para>
          If this is enabled, <literal>TRUNCATE</literal> operations performed
          directly on partitions are not replicated.
         </para>
        </listitem>
       </varlistentry>
      </variablelist></para>
    </listitem>
   </varlistentry>

  </variablelist>

  <para>
   When specifying a parameter of type <type>boolean</type>, the
   <literal>=</literal> <replaceable class="parameter">value</replaceable>
   part can be omitted, which is equivalent to
   specifying <literal>TRUE</literal>.
  </para>
 </refsect1>

 <refsect1>
  <title>Notes</title>

  <para>
   If <literal>FOR TABLE</literal>, <literal>FOR ALL TABLES</literal> or
   <literal>FOR TABLES IN SCHEMA</literal> are not specified, then the
   publication starts out with an empty set of tables.  That is useful if
   tables or schemas are to be added later.
  </para>

  <para>
   The creation of a publication does not start replication.  It only defines
   a grouping and filtering logic for future subscribers.
  </para>

  <para>
   To create a publication, the invoking user must have the
   <literal>CREATE</literal> privilege for the current database.
   (Of course, superusers bypass this check.)
  </para>

  <para>
   To add a table to a publication, the invoking user must have ownership
   rights on the table.  The <command>FOR ALL TABLES</command> and
   <command>FOR TABLES IN SCHEMA</command> clauses require the invoking
   user to be a superuser.
  </para>

  <para>
   The tables added to a publication that publishes <command>UPDATE</command>
   and/or <command>DELETE</command> operations must have
   <literal>REPLICA IDENTITY</literal> defined.  Otherwise those operations will be
   disallowed on those tables.
  </para>

  <para>
   Any column list must include the <literal>REPLICA IDENTITY</literal> columns
   in order for <command>UPDATE</command> or <command>DELETE</command>
   operations to be published. There are no column list restrictions if the
   publication publishes only <command>INSERT</command> operations.
  </para>

  <para>
   A row filter expression (i.e., the <literal>WHERE</literal> clause) must contain only
   columns that are covered by the <literal>REPLICA IDENTITY</literal>, in
   order for <command>UPDATE</command> and <command>DELETE</command> operations
   to be published. For publication of