From: | "Euler Taveira" <euler(at)eulerto(dot)com> |
---|---|
To: | "Alvaro Herrera" <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | "Amit Kapila" <amit(dot)kapila16(at)gmail(dot)com>, "Peter Smith" <smithpb2250(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: | 2021-12-26 22:57:24 |
Message-ID: | efac5ea8-d0c6-4c92-aa82-36ea45fd013a@www.fastmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
--
Euler Taveira
EDB https://www.enterprisedb.com/
From | Date | Subject | |
---|---|---|---|
Next Message | kuroda.hayato@fujitsu.com | 2021-12-27 01:40:00 | RE: Allow escape in application_name |
Previous Message | Corey Huinker | 2021-12-26 22:25:05 | Re: Foreign key joins revisited |