specified. See <xref
linkend="sql-createpublication"/> for details. Note that a subscription
having several publications in which the same table has been published
with different column lists is not supported. See
<xref linkend="logical-replication-col-list-combining"/> for details of
potential problems when altering column lists.
</para>
<para>
If the optional <literal>WHERE</literal> clause is specified, rows for
which the <replaceable class="parameter">expression</replaceable>
evaluates to false or null will not be published. Note that parentheses
are required around the expression. The
<replaceable class="parameter">expression</replaceable> is evaluated with
the role used for the replication connection.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><replaceable class="parameter">schema_name</replaceable></term>
<listitem>
<para>
Name of an existing schema.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>SET ( <replaceable class="parameter">publication_parameter</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] )</literal></term>
<listitem>
<para>
This clause alters publication parameters originally set by
<xref linkend="sql-createpublication"/>. See there for more information.
</para>
<caution>
<para>
Altering the <literal>publish_via_partition_root</literal> parameter can
lead to data loss or duplication at the subscriber because it changes
the identity and schema of the published tables. Note this happens only
when a partition root table is specified as the replication target.
</para>
<para>
This problem can be avoided by refraining from modifying partition leaf
tables after the <command>ALTER PUBLICATION ... SET</command> until the
<link linkend="sql-altersubscription"><command>ALTER SUBSCRIPTION ... REFRESH PUBLICATION</command></link>
is executed and by only refreshing using the <literal>copy_data = off</literal>
option.
</para>
</caution>
</listitem>
</varlistentry>