Re: Proving IS NOT NULL inference for ScalarArrayOpExpr's

From: James Coleman <jtc331(at)gmail(dot)com>
To: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proving IS NOT NULL inference for ScalarArrayOpExpr's
Date: 2019-01-16 01:05:00
Message-ID: CAAaqYe9s0pB9PYpgBLzws8GzQP2ohfa=BZe5wiJtWGtcKAAuQg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jan 15, 2019 at 4:36 PM David Rowley
<david(dot)rowley(at)2ndquadrant(dot)com> wrote:
> I wasn't suggesting any code changes. I just thought the code was
> sufficiently hard to understand to warrant some additional tests that
> ensure we don't assume that if the int4 column x is not null that also
> x+x is not null. Only the reverse can be implied since int4pl is
> strict.

At the risk of missing something obvious, I'm not sure I see a case
where "x is not null" does not imply "(x + x) is not null", at least
for integers. Since an integer + an integer results in an integer,
then it must imply the addition of itself is not null also?

This is the root of the questions I had:

James Coleman <jtc331(at)gmail(dot)com> writes:
> 1. The current code doesn't result in "strongly_implied_by = t" for
> the "(x + x) is not null" case, but it does result in "s_i_holds = t".
> This doesn't change if I switch to using "equal()" as mentioned above.

> 3. The tests I have for refuting "(x + x) is null" show that both
> s_r_holds and w_r_holds. I'd expected these to be false.

James Coleman

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2019-01-16 01:14:03 Re: Proving IS NOT NULL inference for ScalarArrayOpExpr's
Previous Message James Coleman 2019-01-16 01:01:31 Re: Proving IS NOT NULL inference for ScalarArrayOpExpr's