aboutsummaryrefslogtreecommitdiff
path: root/src/backend/utils/adt/jsonpath_exec.c
diff options
context:
space:
mode:
authorJeff Davis <jdavis@postgresql.org>2024-03-19 15:24:41 -0700
committerJeff Davis <jdavis@postgresql.org>2024-03-19 15:24:41 -0700
commitf69319f2f1fb16eda4b535bcccec90dff3a6795e (patch)
tree48077a7e6eb0309218b09a3be483aec37a6f204f /src/backend/utils/adt/jsonpath_exec.c
parentfd0398fcb099980fbedbb7750356ef234408c1c9 (diff)
downloadpostgresql-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