Re: Wrong results from inner-unique joins caused by collation mismatch - Mailing list pgsql-hackers

On Sat, Apr 25, 2026 at 12:44 AM Richard Guo <guofenglinux@gmail.com> wrote:
> On Fri, Apr 24, 2026 at 11:53 PM Tom Lane <tgl@sss.pgh.pa.us> 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