</programlisting>
<programlisting>
/* sub # */ SELECT * FROM child ORDER BY a;
 a
---
 5
 6
 7
(3 rows)
</programlisting></para>

  </sect2>

 </sect1>

 <sect1 id="logical-replication-col-lists">
  <title>Column Lists</title>

  <para>
   Each publication can optionally specify which columns of each table are
   replicated to subscribers. The table on the subscriber side must have at
   least all the columns that are published. If no column list is specified,
   then all columns on the publisher are replicated.
   See <xref linkend="sql-createpublication"/> for details on the syntax.
  </para>

  <para>
   The choice of columns can be based on behavioral or performance reasons.
   However, do not rely on this feature for security: a malicious subscriber
   is able to obtain data from columns that are not specifically
   published.  If security is a consideration, protections can be applied
   at the publisher side.
  </para>

  <para>
   If no column list is specified, any columns added to the table later are
   automatically replicated. This means that having a column list which names
   all columns is not the same as having no column list at all.
  </para>

  <para>
   A column list can contain only simple column references.  The order
   of columns in the list is not preserved.
  </para>

  <para>
   Generated columns can also be specified in a column list. This allows
   generated columns to be published, regardless of the publication parameter
   <link linkend="sql-createpublication-params-with-publish-generated-columns">
   <literal>publish_generated_columns</literal></link>. See
   <xref linkend="logical-replication-gencols"/> for details.
  </para>

  <para>
   Specifying a column list when the publication also publishes
   <link linkend="sql-createpublication-params-for-tables-in-schema"><literal>FOR TABLES IN SCHEMA</literal></link>
   is not supported.
  </para>

  <para>
   For partitioned tables, the publication parameter
   <link linkend="sql-createpublication-params-with-publish-via-partition-root"><literal>publish_via_partition_root</literal></link>
   determines which column list is used. If <literal>publish_via_partition_root</literal>
   is <literal>true</literal>, the root partitioned table's column list is
   used. Otherwise, if <literal>publish_via_partition_root</literal> is
   <literal>false</literal> (the default), each partition's column list is used.
  </para>

  <para>
   If a publication publishes <command>UPDATE</command> or
   <command>DELETE</command> operations, any column list must include the
   table's replica identity columns (see
   <xref linkend="sql-altertable-replica-identity"/>).
   If a publication publishes only <command>INSERT</command> operations, then
   the column list may omit replica identity columns.
  </para>

  <para>
   Column lists have no effect for the <literal>TRUNCATE</literal> command.
  </para>

  <para>
   During initial data synchronization, only the published columns are
   copied.  However, if the subscriber is from a release prior to 15, then
   all the columns in the table are copied during initial data synchronization,
   ignoring any column lists. If the subscriber is from a release prior to 18,
   then initial table synchronization won't copy generated columns even if they
   are defined in the publisher.
  </para>

   <warning id="logical-replication-col-list-combining">
    <title>Warning: Combining Column Lists from Multiple Publications</title>
    <para>
     There's currently no support for subscriptions comprising several
     publications where the same table has been published with different
     column lists.  <xref linkend="sql-createsubscription"/> disallows
     creating such subscriptions, but it is still possible to get into
     that situation by adding or altering column lists on the publication
     side after a subscription has been created.
    </para>
    <para>
     This means changing the column lists of tables on publications that are