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
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 |