On Thu, 2025-10-16 at 15:46 +0200, Peter Eisentraut wrote:
> If it's a variant of PG_UNICODE_FAST, then it ought to be called
> PG_UNICODE_FAST_CI or similar. Otherwise, one would expect it to be
> a
> variant of PG_UNICODE (if that existed, but there is also UNICODE).
>
> But that name is also
On 20.09.25 02:21, Jeff Davis wrote:
New builtin case-insensitive collation PG_UNICODE_CI, where the
ordering semantics are just:
strcmp(CASEFOLD(arg1), CASEFOLD(arg2))
and the character semantics are the same as PG_UNICODE_FAST.
If it's a variant of PG_UNICODE_FAST, then it ought to be c
On Fri, 2025-09-19 at 17:21 -0700, Jeff Davis wrote:
>
> Proposal
>
>
> New builtin case-insensitive collation PG_UNICODE_CI, where the
> ordering semantics are just:
>
>strcmp(CASEFOLD(arg1), CASEFOLD(arg2))
>
> and the character semantics are the same as PG_UNICODE_FAST.
On Fri, 2025-09-19 at 17:21 -0700, Jeff Davis wrote:
> --
> Versioning
> --
>
> Unlike other built-in collations, the order does depend on the
> version
> of Unicode...
> That means that indexes, including primary keys, can become
> inconsistent after a major version upgrade...
T
Proposal
New builtin case-insensitive collation PG_UNICODE_CI, where the
ordering semantics are just:
strcmp(CASEFOLD(arg1), CASEFOLD(arg2))
and the character semantics are the same as PG_UNICODE_FAST.
This does not perform the Unicode Collation algorithm (UCA), and it is
