From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [19] Proposal: function markers to indicate collation/ctype sensitivity |
Date: | 2025-06-11 16:07:59 |
Message-ID: | 35687c56436bf37a987b51dfba59d2e8c35024f0.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 2025-06-11 at 09:06 +0200, Peter Eisentraut wrote:
> > CASE: lower/upper/initcap/fold behavior
> > CLASS: char classifications such as [[:punct:]]
> > ORDER: comparisons
> >
> > Internally, at least for the foreseeable future, CASE and CLASS
> > would
> > be the same. They'd just be different markers to record the user's
> > intent.
>
> Under what scenario would they become different, and how would that
> matter in practice?
I can't think of any reason those behaviors should diverge. If nothing
else, the "uppercase" property should be consistent with the results of
case mapping.
However, I have struggled to come up with a single word that includes
both casing behavior and character classification, but excludes
ordering behavior. Such a word would be useful for documentation, too.
I guess "CTYPE" works, but it's too technical and feels libc-specific.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Florents Tselai | 2025-06-11 16:08:25 | Re: add function for creating/attaching hash table in DSM registry |
Previous Message | Christoph Berg | 2025-06-11 15:53:15 | Re: CHECKPOINT unlogged data |