On Tue, Sep 23, 2025 at 5:27 PM Tom Lane <tgl@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
