Re: Proving IS NOT NULL inference for ScalarArrayOpExpr's - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Proving IS NOT NULL inference for ScalarArrayOpExpr's
Date
Msg-id 24537.1547613450@sss.pgh.pa.us
Whole thread Raw
In response to Re: Proving IS NOT NULL inference for ScalarArrayOpExpr's  (James Coleman <jtc331@gmail.com>)
Responses Re: Proving IS NOT NULL inference for ScalarArrayOpExpr's  (James Coleman <jtc331@gmail.com>)
List pgsql-hackers
James Coleman <jtc331@gmail.com> writes:
> On Tue, Jan 15, 2019 at 3:53 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I quite dislike taking the responsibility out of clause_is_strict_for
>> and putting it in the callers.

> The reason I moved it was that we're no longer just proving
> strictness, so it seemed odd to put it in a function specifically
> named to be about proving strictness.

Well, as I said upthread, it seems like we need to think a bit more
carefully about what it is that clause_is_strict_for is testing ---
and if that ends up finding that some other name is more apposite,
I'd not have any hesitation about renaming it.  But we're really
missing a bet if the ScalarArrayOp-specific check isn't inside that
recursive check of an "atomic" expression's properties.  The
routines above there only recurse through things that act like
AND or OR, but clause_is_strict_for is capable of descending
through other stuff as long as it's strict in some sense.  What
we need to be clear about here is exactly what that sense is.

            regards, tom lane


pgsql-hackers by date:

Previous
From: "Tsunakawa, Takayuki"
Date:
Subject: RE: Libpq support to connect to standby server as priority
Next
From: Tatsuo Ishii
Date:
Subject: Re: Libpq support to connect to standby server as priority