Re: row filtering for logical replication

From: Peter Smith <smithpb2250(at)gmail(dot)com>
To: Euler Taveira <euler(at)eulerto(dot)com>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Ajin Cherian <itsajin(at)gmail(dot)com>, "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>, Greg Nancarrow <gregn4422(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, "tanghy(dot)fnst(at)fujitsu(dot)com" <tanghy(dot)fnst(at)fujitsu(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Rahila Syed <rahilasyed90(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Önder Kalacı <onderkalaci(at)gmail(dot)com>, japin <japinli(at)hotmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, David Steele <david(at)pgmasters(dot)net>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: row filtering for logical replication
Date: 2022-01-04 04:55:11
Message-ID: CAHut+PtXqWzx_0SNLOpKdifxwWptfH6WOpouNxeUpmbWV-yUjg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Dec 27, 2021 at 9:57 AM Euler Taveira <euler(at)eulerto(dot)com> wrote:
>
> On Sun, Dec 26, 2021, at 1:09 PM, Alvaro Herrera wrote:
>
> On 2021-Dec-26, Euler Taveira wrote:
>
> > On Sat, Dec 25, 2021, at 1:20 AM, Amit Kapila wrote:
> > > On Fri, Dec 24, 2021 at 11:04 AM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
> > > >
> > > > So, IMO the PG docs wording for this part should be relaxed a bit.
> > > >
> > > > e.g.
> > > > BEFORE:
> > > > + A nullable column in the <literal>WHERE</literal> clause could cause the
> > > > + expression to evaluate to false; avoid using columns without not-null
> > > > + constraints in the <literal>WHERE</literal> clause.
> > > > AFTER:
> > > > + A nullable column in the <literal>WHERE</literal> clause could cause the
> > > > + expression to evaluate to false. To avoid unexpected results, any possible
> > > > + null values should be accounted for.
>
> Is this actually correct? I think a null value would cause the
> expression to evaluate to null, not false; the issue is that the filter
> considers a null value as not matching (right?). Maybe it's better to
> spell that out explicitly; both these wordings seem distracting.
>
> [Reading it again...] I think it is referring to the
> pgoutput_row_filter_exec_expr() return. That's not accurate because it is
> talking about the expression and the expression returns true, false and null.
> However, the referred function returns only true or false. I agree that we
> should explictily mention that a null return means the row won't be published.
>
> You have this elsewhere:
>
> + If the optional <literal>WHERE</literal> clause is specified, only rows
> + that satisfy the <replaceable class="parameter">expression</replaceable>
> + will be published. Note that parentheses are required around the
> + expression. It has no effect on <literal>TRUNCATE</literal> commands.
>
> Maybe this whole thing is clearer if you just say "If the optional WHERE
> clause is specified, rows for which the expression returns false or null
> will not be published." With that it should be fairly clear what
> happens if you have NULL values in the columns used in the expression,
> and you can just delete that phrase you're discussing.
>
> Your proposal sounds good to me.

Modified as suggested in v58 [1].

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

Kind Regards,
Peter Smith.
Fujitsu Australia

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2022-01-04 05:03:57 Re: Allow escape in application_name
Previous Message Peter Smith 2022-01-04 04:53:37 Re: row filtering for logical replication