Re: UNION versus collations - Mailing list pgsql-hackers

From Laurenz Albe
Subject Re: UNION versus collations
Date
Msg-id aecbaa08cc9b21187daf9304346c4e845c157753.camel@cybertec.at
Whole thread Raw
In response to UNION versus collations  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, 2024-11-18 at 17:56 -0500, Tom Lane wrote:
> prepunion.c's plan_union_children(), which merges
> identically-propertied UNION operations into one, has this comment:
>
>  * NOTE: currently, we ignore collations while determining if a child has
>  * the same properties.  This is semantically sound only so long as all
>  * collations have the same notion of equality.  It is valid from an
>  * implementation standpoint because we don't care about the ordering of
>  * a UNION child's result: UNION ALL results are always unordered, and
>  * generate_union_paths will force a fresh sort if the top level is a UNION.
>
> This argument seems well past its sell-by date.  In the first place,
> now that we have nondeterministic collations we can't assume that
> "all collations have the same notion of equality".
>
> [...]
>
> So I think we ought to apply the attached as far back as we have
> nondeterministic collations.

+1

This also reminded me of [1], where I cannot think of a good fix.

Yours,
Laurenz Albe

 [1]: https://postgr.es/m/8ef4899c4acfebca45cc6c042a6dc611d25ffab1.camel%40cybertec.at



pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Disallow UPDATE/DELETE on table with unpublished generated column as REPLICA IDENTITY
Next
From: Will Mortensen
Date:
Subject: README.tuplock and SHARE lock