Re: Reduce "Var IS [NOT] NULL" quals during constant folding

On Sat, Mar 22, 2025 at 2:21 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Ugh, no, that is *completely* unworkable. Suppose that the user
> does CREATE VIEW, and the parse tree recorded for that claims that
> column X is not-nullable. Then the user drops the not-null
> constraint, and then asks to execute the view. We'll optimize on
> the basis of stale information.

Thanks for pointing this out.

> The way to make this work is what I said before: move the planner's
> collection of relation information to somewhere a bit earlier in
> the planner. But not to outside the planner.

I'm considering moving the collection of attnotnull information before
pull_up_sublinks, in hopes of leveraging this info to pull up NOT IN
in the future, something like attached.

Maybe we could also collect the attgenerated information in the same
routine, making life easier for expand_virtual_generated_columns.

Another issue I found is that in convert_EXISTS_to_ANY, we pass the
parent's root to eval_const_expressions, which can cause problems when
reducing "Var IS [NOT] NULL" quals. To fix, v2 patch constructs up a
dummy PlannerInfo with "glob" link set to the parent's and "parser"
link set to the subquery. I believe these are the only fields used.

Thanks
Richard