public inbox for [email protected]  

help / color / mirror / Atom feed

From: Peter Eisentraut <[email protected]>
To: Jeff Davis <[email protected]>
To: Daniel Verite <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Jeremy Schneider <[email protected]>
Cc: [email protected]
Subject: Re: Built-in CTYPE provider
Date: Mon, 25 Mar 2024 08:29:47 +0100
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]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

On 22.03.24 18:26, Jeff Davis wrote:
> On Fri, 2024-03-22 at 15:51 +0100, Peter Eisentraut wrote:
>> I think this might be too big of a compatibility break.  So far,
>> initcap('123abc') has always returned '123abc'.  If the new collation
>> returns '123Abc' now, then that's quite a change.  These are not some
>> obscure Unicode special case characters, after all.
> 
> It's a new collation, so I'm not sure it's a compatibility break. But
> you are right that it is against documentation and expectations for
> INITCAP().
> 
>> What is the ICU configuration incantation for this?  Maybe we could
>> have
>> the builtin provider understand some of that, too.
> 
> https://unicode-org.github.io/icu-docs/apidoc/dev/icu4c/stringoptions_8h.html#a4975f537b9960f0330b23...
> https://unicode-org.github.io/icu-docs/apidoc/dev/icu4c/stringoptions_8h.html#afc65fa226cac9b8eeef0e...
> 
>> Or we should create a function separate from initcap.
> 
> If we create a new function, that also gives us the opportunity to
> accept optional arguments to control the behavior rather than relying
> on collation for every decision.

Right.  I thought when you said there is an ICU configuration for it, 
that it might be like collation options that you specify in the locale 
string.  But it appears it is only an internal API setting.  So that, in 
my mind, reinforces the opinion that we should leave initcap() as is and 
make a new function that exposes the new functionality.  (This does not 
have to be part of this patch set.)

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]
  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