From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Peter Eisentraut <peter(at)eisentraut(dot)org>, Daniel Verite <daniel(at)manitou-mail(dot)org> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Jeremy Schneider <schneider(at)ardentperf(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Built-in CTYPE provider |
Date: | 2024-04-03 23:19:02 |
Message-ID: | d3b8b238e99f672e2c170eb7ab14ee61fe7fa3a3.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2024-03-26 at 08:14 +0100, Peter Eisentraut wrote:
>
> Full vs. simple case mapping is more of a legacy compatibility
> question,
> in my mind. There is some expectation/precedent that C.UTF-8 uses
> simple case mapping, but beyond that, I don't see a reason why
> someone
> would want to explicitly opt for simple case mapping, other than if
> they
> need length preservation or something, but if they need that, then
> they
> are going to be in a world of pain in Unicode anyway.
I mostly agree, though there are some other purposes for the simple
mapping:
* a substitute for case folding: lower() with simple case mapping will
work better for that purpose than lower() with full case mapping (after
we have casefold(), this won't be a problem)
* simple case mapping is conceptually simpler, and that's a benefit by
itself in some situations -- maybe the 1:1 assumption exists other
places in their application
> > There's also another reason to consider it an argument rather than
> > a
> > collation property, which is that it might be dependent on some
> > other
> > field in a row. I could imagine someone wanting to do:
> >
> > SELECT
> > UPPER(some_field,
> > full => true,
> > dotless_i => CASE other_field WHEN ...)
> > FROM ...
>
> Can you index this usefully? It would only work if the user query
> matches exactly this pattern?
In that example, UPPER is used in the target list -- the WHERE clause
might be indexable. The UPPER is just used for display purposes, and
may depend on some locale settings stored in another table associated
with a particular user.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2024-04-03 23:24:25 | Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~? |
Previous Message | Peter Eisentraut | 2024-04-03 23:10:20 | Re: Security lessons from liblzma - libsystemd |