Re: BUG #19830: Mention that UNIQUE on a nondeterministic ICU collation treats ignorable characters as duplicates

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: aswin(dot)tummala(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #19830: Mention that UNIQUE on a nondeterministic ICU collation treats ignorable characters as duplicates
Date: 2026-11-04 13:46:13
Message-ID: ae1fcac5-5f42-4e75-939d-a42be94472c4@eisentraut.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 04.11.26 02:43, PG Bug reporting form wrote:
> When migrating from SQL Server, we found that a UNIQUE constraint on a
> column with und-u-ks-level2 (deterministic = false)
> rejects 'ACME' || U&'\200B' as a duplicate of 'ACME'. The same data loads
> fine into a citext column. Section 23.2.3.1 does show
> U+2063 being ignored, but it doesn't say what that means for constraints.
> A short note under "Nondeterministic Collations" would
> have saved us time. It could say that ignorable code points (zero-width
> space, soft hyphen, BOM, most control characters) don't
> count toward uniqueness, and that this differs from citext.

What you are observing is a very specific combination of several
features. It would be extremely niche and redundant to document this
particular case.

I would think that if you understand what nondeterministic collations
are (and you have chosen to use them) and you know what unique
constraints are, then this behavior would follow from that. We could
perhaps try to clarify this somehow, but it would have to be in more
general terms.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Fujii Masao 2026-11-04 13:55:33 Re: BUG #19775: Incremental backup without data checksums restores a stale visibility map page after VACUUM truncati
Previous Message Hayato Kuroda (Fujitsu) 2026-11-04 13:24:04 RE: Streaming decoding fails with "unexpected table_index_fetch_tuple call during logical decoding" when a relation has a TOASTed conbin (follow-up to BUG #18641)