On Fri, Mar 21, 2025 at 10:21 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.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.
