On Thu, 27 Nov 2025 at 00:55, Richard Guo <[email protected]> wrote:
>
> On Tue, Nov 25, 2025 at 10:16 PM David Rowley <[email protected]> wrote:
> > uhh, of course it is. That's what I did in [1] for Consts. Doing it
> > this way means we'll not need to modify the constant folding code (or
> > whichever other code wants to know when an Expr can't be NULL) every
> > time we think of something new that we can prove can't be NULL.
>
> OK.  Here is an updated patch that does that.  (There is some overlap
> in changes to expr_is_nonnullable with the patch you mentioned.)

I've pushed 42473b3b3 now. I think you should maybe do this as 2
commits. 0001 to make eval_const_expressions_mutator() use
expr_is_nonnullable() instead of var_is_nonnullable(). That'll not
really do anything aside from the additional Const support for
NULLability checks. Otherwise, it's nearly a refactor.  0002 is to add
the COALESCE code to expr_is_nonnullable(). That way you can sell this
one for a bit more than your initial use case, as it'll also then
handle converting things like COUNT(COALESCE(nullable, notnullable))
into COUNT(*). I think doing it this way means you don't need to argue
that optimising COALESCE(...) IS NOT NULL is worthwhile since you're
really just teaching expr_is_nonnullable() about COALESCE Nodes.

David


Reply via email to