Re: constraint exclusion and nulls in IN (..) clause - Mailing list pgsql-hackers

From Amit Langote
Subject Re: constraint exclusion and nulls in IN (..) clause
Date
Msg-id b0501496-5290-9fea-e704-6c5e9abbef31@lab.ntt.co.jp
Whole thread Raw
In response to Re: constraint exclusion and nulls in IN (..) clause  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: constraint exclusion and nulls in IN (..) clause  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2018/03/21 23:00, Tom Lane wrote:
> Emre Hasegeli <emre@hasegeli.com> writes:
>> I am not sure if we are covering the case when clause_const and
>> pred_const are both NULL.  In this case, we should be able to return
>> true only by checking op_strict(pred_op) or maybe even without
>> checking that.  Am I mistaken?
> 
> Yeah, that's there.  We need both operators to be strict, I think;
> otherwise we can't really assume anything about what they'd return
> for NULL inputs.  But if they are, we have NULL => NULL which is
> valid for all proof cases.

Thank you for closing the CF entry.

I too wasn't sure if the patch's modifications to
operator_predicate_proof() led to correct handling for the case where both
clause_const and pred_const are both NULL consts.  ISTM that the result in
that case becomes what operator_same_subexprs_proof() would return for the
pred_op (possibly commuted) and clause_op pair.  But maybe we don't end up
in that case much.

Regards,
Amit



pgsql-hackers by date:

Previous
From: Jeevan Chalke
Date:
Subject: Re: [HACKERS] Partition-wise aggregation/grouping
Next
From: Jeevan Chalke
Date:
Subject: Re: [HACKERS] Partition-wise aggregation/grouping