diff options
author | Jeff Davis <jdavis@postgresql.org> | 2024-03-19 15:24:41 -0700 |
---|---|---|
committer | Jeff Davis <jdavis@postgresql.org> | 2024-03-19 15:24:41 -0700 |
commit | f69319f2f1fb16eda4b535bcccec90dff3a6795e (patch) | |
tree | 48077a7e6eb0309218b09a3be483aec37a6f204f /src/backend/utils/adt/jsonpath_exec.c | |
parent | fd0398fcb099980fbedbb7750356ef234408c1c9 (diff) | |
download | postgresql-f69319f2f1fb16eda4b535bcccec90dff3a6795e.tar.gz postgresql-f69319f2f1fb16eda4b535bcccec90dff3a6795e.zip |
Support C.UTF-8 locale in the new builtin collation provider.
The builtin C.UTF-8 locale has similar semantics to the libc locale of
the same name. That is, code point sort order (fast, memcmp-based)
combined with Unicode semantics for character operations such as
pattern matching, regular expressions, and
LOWER()/INITCAP()/UPPER(). The character semantics are based on
Unicode simple case mappings.
The builtin provider's C.UTF-8 offers several important advantages
over libc:
* faster sorting -- benefits from additional optimizations such as
abbreviated keys and varstrfastcmp_c
* faster case conversion, e.g. LOWER(), at least compared with some
libc implementations
* available on all platforms with identical semantics, and the
semantics are stable, testable, and documentable within a given
Postgres major version
Being based on memcmp, the builtin C.UTF-8 locale does not offer
natural language sort order. But it is an improvement for most use
cases that might otherwise use libc's "C.UTF-8" locale, as well as
many use cases that use libc's "C" locale.
Discussion: https://postgr.es/m/ff4c2f2f9c8fc7ca27c1c24ae37ecaeaeaff6b53.camel%40j-davis.com
Reviewed-by: Daniel Vérité, Peter Eisentraut, Jeremy Schneider
Diffstat (limited to 'src/backend/utils/adt/jsonpath_exec.c')
0 files changed, 0 insertions, 0 deletions