Horton

Re: PostgreSQL 18 GA press release draft

Jeff Davis <pgsql@j-davis.com>

View thread
From: Jeff Davis <pgsql@j-davis.com>
To: Nico Williams <nico@cryptonector.com>
Cc: "Jonathan S. Katz" <jkatz@postgresql.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-09-12T19:13:23Z
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. Add modern SHA-2 based password hashes to pgcrypto.

  2. Convert 'x IN (VALUES ...)' to 'x = ANY ...' then appropriate

  3. Allow usage of match_orclause_to_indexcol() for joins

On Fri, 2025-09-12 at 13:21 -0500, Nico Williams wrote:
> On Fri, Sep 12, 2025 at 10:11:59AM -0700, Jeff Davis wrote:
> > The name PG_UNICODE_FAST is meant to convey that it provides full
> > unicode semantics for case mapping and pattern matching, while also
> > being fast because it uses memcmp for comparisons. While the name
> > PG_C_UTF8 is meant to convey that it's closer to what users of the
> > libc
> > "C.UTF-8" locale might expect.
> 
> How does one do form-insensitive comparisons?

If you mean case insensitive matching, you can do:

   CASEFOLD(a) = CASEFOLD(b)

in any locale or provider, but it's best when using PG_UNICODE_FAST or
ICU, because it handles some nuances better. For instance:

   CASEFOLD('ß') = CASEFOLD('SS') AND
   CASEFOLD('ß') = CASEFOLD('ss') AND
   CASEFOLD('ß') = CASEFOLD('ẞ')

are all true in PG_UNICODE_FAST and "en-US-x-icu", but not in libc
collations.

ICU also has case-insensitive collations, which offer a bit more
flexibility:

https://www.postgresql.org/docs/current/collation.html#COLLATION-NONDETERMINISTIC

Regards,
	Jeff Davis