| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Daniel Verite <daniel(at)manitou-mail(dot)org> |
| Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers(at)postgresql(dot)org, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Vik Fearing <vik(at)2ndquadrant(dot)fr> |
| Subject: | Re: Does UCS_BASIC have the right CTYPE? |
| Date: | 2023-10-26 23:27:10 |
| Message-ID: | 6cb2b2d9112ed17250d55a757d2db9f2d1042f53.camel@j-davis.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 2023-10-26 at 17:32 -0400, Tom Lane wrote:
> For starters, C locale should certainly act different from others.
Agreed. ctype of "C" is 100% stable (as implemented in Postgres with
special ASCII-only semantics) and simple.
I'm looking for a way to offer a new middle ground between plain "C"
and buying into all of the problems with collation providers and
localization. We don't need to remove functionality to do so.
Providing Unicode ctype behavior doesn't look very hard. Collations
could select it either with a special name or by using the "builtin"
provider I proposed earlier. If the behavior does change with a new
Unicode version it would be easier to see and less likely to affect on-
disk structures than a collation change.
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2023-10-27 00:15:19 | Re: Is this a problem in GenericXLogFinish()? |
| Previous Message | Tom Lane | 2023-10-26 23:21:24 | Re: Document parameter count limit |