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
