On Wed, Sep 9, 2026 at 11:35 PM Tom Lane <[email protected]> wrote: > The one nit I can find to pick with this is that I don't really like > the description of the clauses of concern as "textually identical". > That makes it sound like surface syntax details (like number of > spaces or presence of an unnecessary table qualifier) matter. > Perhaps say "parse-tree identical", or "equal()"? That seems a bit > jargony but I have no better ideas.
Agreed, I've switched to "parse-tree identical" in both the comment and the commit message. > I wonder if we are going to push the rinfo_serial mechanism too far. > But that's just a vague feeling of discomfort, I can't say there is > anything wrong with fixing it this way. Right, I have a similar feeling. It seems that rinfo_serial is becoming more and more load-bearing as a general "this is the same condition" key. But I couldn't find a better solution, and it's already what create_nestloop_path relies on to drop conditions that are due to be moved into the inner path. Maybe this is something we need to revisit in the future when we have a better mechanism. > I wonder if we should leave the Assert bits out of v19. The intent to > have hard prevention of duplicate clauses is a brand new aspiration, > and I have pretty much no faith that no such cases remain. I don't > really want to commit to fixing all such cases in v19. Fair point. I kept the assertions on HEAD only, with a note in the commit message. I've pushed both to master and v19. - Richard
