Re: PG DOCS - logical replication filtering - Mailing list pgsql-hackers

On Mon, Apr 11, 2022 at 1:27 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Fri, Apr 8, 2022 at 11:42 AM Peter Smith <smithpb2250@gmail.com> wrote:
> >
> > On Wed, Apr 6, 2022 at 8:58 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > >
> >
> > > 3.
> > > +   <para>
> > > +    Whenever an <command>UPDATE</command> is processed, the row filter
> > > +    expression is evaluated for both the old and new row (i.e. before
> > > +    and after the data is updated).
> > > +   </para>
> > > +
> > > +   <para>
> > > +    If both evaluations are <literal>true</literal>, it replicates the
> > > +    <command>UPDATE</command> change.
> > > +   </para>
> > > +
> > > +   <para>
> > > +    If both evaluations are <literal>false</literal>, it doesn't replicate
> > > +    the change.
> > > +   </para>
> > >
> > > I think we can combine these three separate paragraphs.
> >
> > The first sentence is the explanation, then there are the 3 separate
> > “If …” cases mentioned. It doesn’t seem quite right to group just the
> > first 2 “if…” cases into one paragraph, while leaving the 3rd one
> > separated. OTOH combining everything into one big paragraph seems
> > worse. Please confirm if you still want this changed.
> >
>
> Yeah, I think we should have something like what Euler's version had
> and maybe keep a summary section from the current patch.
>

Modified in v7 [1]. Removed the bullets. Structured the text
paragraphs the same way that Euler had it. The summary is kept as-is.


> > > 5.
> > > +   <note>
> > > +    <para>
> > > +     Publication <literal>publish</literal> operations are ignored
> > > when copying pre-existing table data.
> > > +    </para>
> > > +   </note>
> > > +
> > > +   <note>
> > > +    <para>
> > > +     If the subscriber is in a release prior to 15, copy pre-existing data
> > > +     doesn't use row filters even if they are defined in the publication.
> > > +     This is because old releases can only copy the entire table data.
> > > +    </para>
> > > +   </note>
> > >
> > > I don't see the need for the first <note> here, the second one seems
> > > to convey it.
> >
> > Well, the 2nd note is only about compatibility with older versions
> > doing the subscribe. But the 1st note is not version-specific at all.
> > It is saying that the COPY does not take the “publish” option into
> > account. If you know of some other docs already mentioning this subtle
> > behaviour of the COPY then I can remove this note and just
> > cross-reference to the other place. But I did not know anywhere this
> > is already mentioned, so that is why I wrote the note about it.
> >
>
> I don't see the need to say about general initial sync (COPY) behavior
> here. It is already defined at [1]. If we want to enhance, we can do
> that as a separate patch to make changes where the initial sync is
> explained. I am not sure that is required though.
>

Did you miss providing the link URL? Anyway, I removed the note in v7
[1]. This information can be done as a separate patch one day (or not
at all).

> I feel in the initial "Row Filters" and "Row Filter Rules" sections,
> we don't need to have separate paragraphs. I think the same is pointed
> out by Alvaro as well.
>

Modified in v7 [1] those sections as suggested. I also assumed these
were the same sections that Alvaro was referring to.

------
[1] https://www.postgresql.org/message-id/CAHut%2BPt1X%3D3VaWRbx3yHByEMC-GPh4oeeMeJKJeTmOELDxZJHQ%40mail.gmail.com

Kind Regards,
Peter Smith.
Fujitsu Australia