Horton

Re: Support LIKE with nondeterministic collations

Nico Williams <nico@cryptonector.com>

View thread
From: Nico Williams <nico@cryptonector.com>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Daniel Verite <daniel@manitou-mail.org>, Peter Eisentraut <peter@eisentraut.org>, Robert Haas <robertmhaas@gmail.com>, Pgsql-Hackers <pgsql-hackers@postgresql.org>
Date: 2026-05-18T11:51:53Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Support LIKE with nondeterministic collations

On Wed, Jul 31, 2024 at 03:26:34PM -0700, Jeff Davis wrote:
> On Fri, 2024-05-03 at 16:58 +0200, Daniel Verite wrote:
> > In other words it says that
> > 
> >   col LIKE 'smith%' collate "nd"
> > 
> > is equivalent to:
> > 
> >   col >= 'smith' collate "nd" AND col < U&'smith\ffff' collate "nd"
> 
> That logic seems to assume something about the collation. If you have a
> collation that orders strings by their sha256 hash, that would entirely
> break the connection between prefixes and ranges, and it wouldn't work.

The hash of what? each character's names or canonical representations in
some UTF?  If so, then, to maintain the above equivalence one would have
to alter the definition of this 'hash-based collation' so that U+FFFF is
always "last".

> Is there something about the way collations are defined that inherently
> maintains a connection between a prefix and a range? [...]

Yes: rules like the one Daniel described.

>                                               [...]? Does it remain
> true even when strange rules are added to a collation?

There are 'strange rules' which cannot be used in defining a collation,
as the result would not then be a collation.

Nico
--