Message-ID: <fc41e598-53e5-43f1-b74b-db47252fd5cf@ardentperf.com>
Date: Wed, 20 Dec 2023 16:29:02 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Built-in CTYPE provider
Content-Language: en-US
From: Jeremy Schneider <schneider@ardentperf.com>
To: pgsql-hackers@lists.postgresql.org, "Davis, Jeff" <jefdavj@amazon.com>
References: <ff4c2f2f9c8fc7ca27c1c24ae37ecaeaeaff6b53.camel@j-davis.com>
 <8a1ae216-8150-41e2-a98d-09c57e3dc90f@ardentperf.com>
 <c2bd1922-f18d-4021-9d39-b373e8b98e16@ardentperf.com>
In-Reply-To: <c2bd1922-f18d-4021-9d39-b373e8b98e16@ardentperf.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/fc41e598-53e5-43f1-b74b-db47252fd5cf%40ardentperf.com>
Precedence: bulk

On 12/20/23 4:04 PM, Jeremy Schneider wrote:
> On 12/20/23 3:47 PM, Jeremy Schneider wrote:
>> On 12/5/23 3:46 PM, Jeff Davis wrote:
>>> CTYPE, which handles character classification and upper/lowercasing
>>> behavior, may be simpler than it first appears. We may be able to get
>>> a net decrease in complexity by just building in most (or perhaps all)
>>> of the functionality.
>>
>> I'll be honest, even though this is primarily about CTYPE and not
>> collation, I still need to keep re-reading the initial email slowly to
>> let it sink in and better understand it... at least for me, it's complex
>> to reason through. 🙂
>>
>> I'm trying to make sure I understand clearly what the user impact/change
>> is that we're talking about: after a little bit of brainstorming and
>> looking through the PG docs, I'm actually not seeing much more than
>> these two things you've mentioned here: the set of regexp_* functions PG
>> provides, and these three generic functions. That alone doesn't seem
>> highly concerning.
> 
> I missed citext, which extends impact to replace(), split_part(),
> strpos() and translate().  There are also the five *_REGEX() functions
> from the SQL standard which I assume are just calling the PG functions.

found some more. here's my running list of everything user-facing I see
in core PG code so far that might involve case:

* upper/lower/initcap
* regexp_*() and *_REGEXP()
* ILIKE, operators ~* !~* ~~ !~~ ~~* !~~*
* citext + replace(), split_part(), strpos() and translate()
* full text search - everything is case folded
* unaccent? not clear to me whether CTYPE includes accent folding
* ltree
* pg_trgm
* core PG parser, case folding of relation names


-- 
http://about.me/jeremy_schneider