Re: Proving IS NOT NULL inference for ScalarArrayOpExpr's

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

David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> writes:
> On Wed, 16 Jan 2019 at 14:29, James Coleman <jtc331(at)gmail(dot)com> wrote:
>> Is your preference in this kind of case to comment the code and/or
>> tests but stick with int4pl even though it doesn't demonstrate the
>> "problem", or try to engineer a different test case such that the
>> *_holds results in the tests don't seem to imply we could prove more
>> things than we do?

> I think using x+x or whatever is fine. I doubt there's a need to
> invent some new function that returns NULL on non-NULL input. The
> code you're adding has no idea about the difference between the two.
> It has no way to know that anyway.

Yeah, I never intended that the *_holds results would be "exact" in
every test case. They're mostly there to catch egregious errors in
test construction. Since the code we're actually testing doesn't get
to see the input or output values of the test cases, it's not really
useful to insist that the test cases exercise every possible combination
of input/output values for the given expressions.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-01-16 04:51:40 Re: Bump up PG_CONTROL_VERSION on HEAD
Previous Message Tatsuo Ishii 2019-01-16 04:42:04 Re: Libpq support to connect to standby server as priority