Date: Sat, 29 Jun 2024 15:08:57 -0700
From: Noah Misch <noah@leadboat.com>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Peter Eisentraut <peter@eisentraut.org>,
	Daniel Verite <daniel@manitou-mail.org>,
	Robert Haas <robertmhaas@gmail.com>,
	Jeremy Schneider <schneider@ardentperf.com>,
	pgsql-hackers@postgresql.org
Subject: Re: Built-in CTYPE provider
Message-ID: <20240629220857.fb.nmisch@google.com>
References: <3bc653b5d562ae9e2838b11cb696816c328a489a.camel@j-davis.com>
 <163f4e2190cdf67f67016044e503c5004547e5a9.camel@j-davis.com>
 <6bdb98e68b2b05aa71f7f934e227738eac84ecee.camel@j-davis.com>
 <19b34a70-f5cf-4faf-88dc-917db44ed48d@eisentraut.org>
 <846a7e1fa2024918b58ff7583523a2f3de9a11b4.camel@j-davis.com>
 <3117d30aa911b408b90420f4f280fa0c3b5851be.camel@j-davis.com>
 <4135cf11-206d-40ed-96c0-9363c1232379@eisentraut.org>
 <7451f81ba0cb512222ab759de8ca1cffe44e9acb.camel@j-davis.com>
 <1f309153-8198-4efa-86dd-8c304ec0040c@eisentraut.org>
 <a21b515000f121244db2a5570d4292d19df23379.camel@j-davis.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <a21b515000f121244db2a5570d4292d19df23379.camel@j-davis.com>
User-Agent: Mutt/2.2.12 (2023-09-09)
Archived-At: <https://www.postgresql.org/message-id/20240629220857.fb.nmisch%40google.com>
Precedence: bulk

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/7089acb3ebac0c1682a79c8bc16803cf06896fb9.camel@j-davis.com
[2] https://postgr.es/m/5a1ecc40539f36cac5b27a62739a45a49785ca54.camel@j-davis.com