On Wed, Sep 9, 2026 at 11:35 PM Tom Lane <tgl@sss.pgh.pa.us> 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
