Re: typos - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: typos
Date
Msg-id CAA4eK1+ScP3=ORCrYm=BPFn5zneJfN41XtupAnTjOhD=3DnP0w@mail.gmail.com
Whole thread Raw
In response to Re: typos  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: typos  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
On Tue, Apr 19, 2022 at 4:35 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
> Yeah, more invasive rewording seems called for.  I propose this:
>
>    For publications containing partitioned tables, the row filter for each
>    partition is taken from the published partitioned table if the
>    publication parameter <literal>publish_via_partition_root</literal> is true,
>    or from the partition itself if it is false (the default).
>
> I think we should also mention that this parameter affects row filters,
> in the <varlistentry> for the WITH clause.  Currently it has
>
>         <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>
>
> I propose to add
>
>         <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>
>          This parameter also affects how row filters are chosen for partitions;
>          see below for details.
>         </para>
>

Your proposed changes look good to me but I think all these places
need to mention 'column list' as well because the behavior is the same
for it.

> More generally, I think we need to connect the WHERE keyword with "row
> filters" more explicitly.  Right now, the parameter reference says
>
>       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. It has no effect on
>       <literal>TRUNCATE</literal> commands.
>
> I propose to make it "If the optional WHERE clause is specified, it
> defines a <firstterm>row filter</firstterm> expression.  Rows for which
> the row filter expression evaluates to false ..."
>

Looks good to me.

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: effective_io_concurrency and NVMe devices
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: TRAP: FailedAssertion("tabstat->trans == trans", File: "pgstat_relation.c", Line: 508