Re: BUG #19007: Planner fails to choose partial index with spurious 'not null'

On Mon, 4 Aug 2025 at 05:19, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I had thought that e2debb643 would fix this in HEAD, since it moved
> the throw-it-away behavior into eval_const_expressions which is also
> applied to index predicates.  Testing shows not, which feels like a
> bug.  It is not okay that eval_const_expressions' behavior varies
> depending on context; we need it to act the same on index
> expressions/predicates as on query expressions.  Maybe we should
> give up on trying to pre-apply eval_const_expressions to the
> relcache's copies of the index expressions, and just do that part
> during plancat's collection of the info?

I guess it doesn't because in RelationGetIndexPredicate(), the call to
eval_const_expressions() passes NULL for the PlannerInfo, resulting in
the NOT NULL information not being available during
eval_const_expressions().

Looks like we keep the indpred varnos as 1 during
RelationGetIndexPredicate() and only change them to the actual varno
of the relation after that call inside get_relation_info(), so it
wouldn't be valid to pass the PlannerInfo down without first rewriting
the varnos and it doesn't seem correct to rewrite the varnos in the
relcache code.

Seems like what it would take to make this work is *another* call to
eval_const_expressions() inside get_relation_info() just after the
varnos have been changed. The attached seems to work. However, it
seems a bit annoying to have to call eval_const_expressions() all over
again for such a rare case. I think it only really covers this rather
silly case, which Bryan seems well aware that the fix is to make the
index non-partial again.

David