public inbox for [email protected]  

help / color / mirror / Atom feed

From: Noah Misch <[email protected]>
To: Jeff Davis <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: Daniel Verite <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Jeremy Schneider <[email protected]>
Cc: [email protected]
Subject: Re: Built-in CTYPE provider
Date: Sat, 29 Jun 2024 15:08:57 -0700
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

On Wed, Mar 20, 2024 at 05:13:26PM -0700, Jeff Davis wrote:
> On Tue, 2024-03-19 at 13:41 +0100, Peter Eisentraut wrote:
> > * v25-0002-Support-C.UTF-8-locale-in-the-new-builtin-collat.patch
> > 
> > Looks ok.
> 
> Committed.

>       <varlistentry>
> +      <term><literal>pg_c_utf8</literal></term>
> +      <listitem>
> +       <para>
> +        This collation sorts by Unicode code point values rather than natural
> +        language order.  For the functions <function>lower</function>,
> +        <function>initcap</function>, and <function>upper</function>, it uses
> +        Unicode simple case mapping.  For pattern matching (including regular
> +        expressions), it uses the POSIX Compatible variant of Unicode <ulink
> +        url="https://www.unicode.org/reports/tr18/#Compatibility_Properties">Compatibility
> +        Properties</ulink>.  Behavior is efficient and stable within a
> +        <productname>Postgres</productname> major version.  This collation is
> +        only available for encoding <literal>UTF8</literal>.
> +       </para>
> +      </listitem>
> +     </varlistentry>

lower(), initcap(), upper(), and regexp_matches() are PROVOLATILE_IMMUTABLE.
Until now, we've delegated that responsibility to the user.  The user is
supposed to somehow never update libc or ICU in a way that changes outcomes
from these functions.  Now that postgresql.org is taking that responsibility
for builtin C.UTF-8, how should we govern it?  I think the above text and [1]
convey that we'll update the Unicode data between major versions, making
functions like lower() effectively STABLE.  Is that right?

(This thread had some discussion[2] that datcollversion/collversion won't
necessarily change when a major versions changes lower() behavior.)

[1] https://postgr.es/m/[email protected]
[2] https://postgr.es/m/[email protected]

view thread (39+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Built-in CTYPE provider
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox