On Sat, Apr 25, 2026 at 12:44 AM Richard Guo <[email protected]> wrote: > On Fri, Apr 24, 2026 at 11:53 PM Tom Lane <[email protected]> wrote: > > 1. I think there are other places in the planner that will need > > substantially this same logic. I recommend breaking out a > > subroutine defined more or less as "do these collations have > > equivalent notions of equality".
> Right. I just found several other places that need this same logic, > which are in query_is_distinct_for(). Without it, we produce wrong > results: 0001 wrapped the logic in subroutine collations_are_compatible(). (I'm a little unsure about the InvalidOid cases. The current implementation treats InvalidOid on either side as compatible, as absence of a collation can't conflict with the other side. This generalizes the asymmetric treatment in IndexCollMatchesExprColl().) 0002 fixed query_is_distinct_for(), using that subroutine. - Richard
v2-0001-Consider-collation-when-proving-uniqueness-from-u.patch
Description: Binary data
v2-0002-Consider-collation-when-proving-subquery-uniquene.patch
Description: Binary data
