Robert Haas writes:
> The use of the terms "refutes", "non-truth", and "non-falsity" drive
> me a little batty; they've all got an internal negation built into
> them, and that's confusing. It seems very tempting to propose getting
> rid of predicate_refuted_by altogether and to simply have one
>
On Thu, Mar 8, 2018 at 6:24 PM, Tom Lane wrote:
> * R1: A refutes B if truth of A implies falsity of B.
> * R2: A refutes B if truth of A implies non-truth of B.
> * R3: A refutes B if non-falsity of A implies non-truth of B.
> * R4: A refutes B if non-falsity of A implies falsity of B.
The use o
Robert Haas writes:
> On Thu, Mar 8, 2018 at 12:33 AM, Tom Lane wrote:
>> A bit of hacking later, I have the attached. The set of test cases it
>> includes at the moment were mostly developed with an eye to getting to
>> full code coverage of predtest.c, but we could add more later. What's
>> r
Robert Haas writes:
> On Thu, Mar 8, 2018 at 12:33 AM, Tom Lane wrote:
>> I'm not sure that that's worth fixing right now. Instead I'm tempted
>> to revert the addition of the clause_is_check argument to
>> predicate_refuted_by, on the grounds that it's both broken and currently
>> unnecessary.
On Thu, Mar 8, 2018 at 12:33 AM, Tom Lane wrote:
> A bit of hacking later, I have the attached. The set of test cases it
> includes at the moment were mostly developed with an eye to getting to
> full code coverage of predtest.c, but we could add more later. What's
> really interesting is that i
In the thread about being able to prove constraint exclusion from
an IN clause mentioning a NULL,
https://www.postgresql.org/message-id/flat/3bad48fc-f257-c445-feeb-8a2b2fb62...@lab.ntt.co.jp
I expressed concern about whether there were existing bugs in predtest.c
given the lack of clarity of the c
