Re: Built-in CTYPE provider

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.

I just saw the krb_caseins_users GUC, which reminds me that PLs also
have their own case functions. And of course extensions. I'm not saying
any of this is in scope for the change here, but I'm just trying to wrap
my brain around all the places we've got CTYPE processing happening, to
better understand the big picture. It might help tease out unexpected
small glitches from changing one thing but not another one.

-Jeremy

--
http://about.me/jeremy_schneider