Re: insensitive collations
Daniel Verite <daniel@manitou-mail.org>
From: "Daniel Verite" <daniel@manitou-mail.org>
To: "Jim Finnerty" <jfinnert@amazon.com>
Cc: pgsql-hackers@postgresql.org
Date: 2021-04-03T20:23:45Z
Lists: pgsql-hackers
Jim Finnerty wrote:
> SET client_encoding = WIN1252;
> [...]
> postgres=# SELECT * FROM locations WHERE location LIKE 'Franche-Comt__'; --
> the wildcard is applied byte by byte instead of character by character, so
> the 2-byte accented character is matched only by 2 '_'s
> location
> ----------------
> Franche-Comté
> (1 row)
The most plausible explanation is that the client-side text is encoded
in UTF-8, rather than WIN1252 as declared.
If you added length('Franche-Comté') to the above query, I suspect
it would tell that the string is one character longer than
expected, and octet_length('Franche-Comté') would be
two-byte longer than expected.
Also dumping the contents of the "location" column with
convert_to() would show that the accents have been
wrongly translated, if the explanation of the encoding snafu is
correct.
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: https://www.manitou-mail.org
Twitter: @DanielVerite
Commits
-
Collations with nondeterministic comparison
- 5e1963fb764e 12.0 landed
-
Add support for collation attributes on older ICU versions
- b8f9a2a69a27 12.0 landed
-
Make type "name" collation-aware.
- 586b98fdf1aa 12.0 cited
-
Make collation-aware system catalog columns use "C" collation.
- 6b0faf723647 12.0 cited
-
Adjust string comparison so that only bitwise-equal strings are considered
- 656beff59033 8.2.0 cited