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

On Fri, Mar 21, 2025 at 10:21 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > However, I'm a bit concerned about the overall premise of the patch
> > set. It feels like it is moving something that really ought to happen
> > at optimization time back to parse time. I have a feeling that's going
> > to break something, although I am not sure right now exactly what.
>
> 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.
>
> 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.
>

Reading this reminded me of the existing issue in [1] where we've broken
session isolation of temporary relation data. There it feels like we are
making decisions in the parser that really belong in the planner since
catalog data is needed to determine relpersistence in many cases. If we
are looking for a spot "earlier in the planner" to attach relation
information, figuring out how to use that to improve matters related to
relpersistence seems warranted.

David J.

[1]
https://www.postgresql.org/message-id/4xxau766dofbwugeyvjftra3g5f7ifaal2clgrbpr7jqotr4av%40d3ige2krpoza