On Tue, Sep 23, 2025 at 5:27 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > What I'm saying is that I'd be much happier with 0003 if it looked > about like the attached. We do not need a heap of mechanism > redundantly proving that the planner is getting these things right > (and potentially containing its own bugs).
Thanks for the demo. That doesn't actually Assert anything, so the commit message is a lie, but I get the point, and based on that, I think what we should do is just drop 0003 altogether for now. I don't need the ojrelids field for anything currently, and if I or someone else does later, we can always revisit this idea. Or, if it turns out that we later introduce more bugs that my version of 0003 would have caught, we can re-ask the question of whether we want to Assert something. I don't agree with your judgement that this is an unreasonable amount of mechanism for what it checks, but I'm entirely prepared to concede that 0003 is kind of clunky, and I also think that the rate at which we do new things in the planner is low enough that it could easily be decades or forever before we have another problem that this would have caught. Hence, I'm fine with dropping this patch. Let's call it "some code that Robert found useful for personal testing" and move on. > > Note that my goal for > > this commitfest was to get 0001-0004 committed, partly because I > > wasn't too sure whether the later patches might need some adjustment. > > Fair enough. I think we can reach agreement on that much pretty quickly. Cool. Let's focus on 0004 then, and possibly 0005 since it's somewhat related and you seem to have an idea that there could be a better way of solving that problem. That's not necessarily to say that 0005 would get committed this CF, unless we happen to agree vigorously on something, but if there's a way to work around needing 0005 or if it needs to be redone in some other form, it would be good to have some idea around that sooner rather than later. -- Robert Haas EDB: http://www.enterprisedb.com
