Re: Built-in CTYPE provider
Jeff Davis <pgsql@j-davis.com>
Attachments
- v14-0001-Minor-cleanup-for-unicode-update-build-and-test.patch (text/x-patch) patch v14-0001
- v14-0002-Add-Unicode-property-tables.patch (text/x-patch) patch v14-0002
- v14-0003-Add-unicode-case-mapping-tables-and-functions.patch (text/x-patch) patch v14-0003
- v14-0004-Catalog-changes-preparing-for-builtin-collation-.patch (text/x-patch) patch v14-0004
- v14-0005-Introduce-collation-provider-builtin-for-C-and-C.patch (text/x-patch) patch v14-0005
On Wed, 2023-12-20 at 13:49 +0100, Daniel Verite wrote: > > But C.UTF-8 is not available everywhere, and there's still the > problem that Unicode updates through libc are not aligned > with Postgres releases. Attached is an implementation of a built-in provider for the "C.UTF-8" locale. That way applications (and tests!) can count on C.UTF-8 always being available on any platform; and it also aligns with the Postgres Unicode updates. Documentation is sparse and the patch is a bit rough, but feedback is welcome -- it does have some basic tests which can be used as a guide. The C.UTF-8 locale, briefly, is a UTF-8 locale that provides simple collation semantics (code point order) but rich ctype semantics (lower/upper/initcap and regexes). This locale is for users who want proper Unicode semantics for character operations (upper/lower, regexes), but don't need a specific natural-language string sort order to apply to all queries and indexes in their system. One might use it as the database default collation, and use COLLATE clauses (i.e. COLLATE UNICODE) where more specific behavior is needed. The builtin C.UTF-8 locale has the following advantages over using the libc C.UTF-8 locale: * Collation performance: the builtin provider uses memcmp and abbreviated keys. In libc, these advantages are only available for the C locale. * Unicode version is aligned with other parts of Postgres, like normalization. * Available on all platforms with exactly the same semantics. * Testable and documentable. * Avoids index corruption risks. In theory libc C.UTF-8 should also have stable collation, but that is not 100% true. In the builtin provider it is 100% stable. Regards, Jeff Davis
Commits
-
Support PG_UNICODE_FAST locale in the builtin collation provider.
- d3d098316913 18.0 landed
-
Support Unicode full case mapping and conversion.
- 286a365b9c25 18.0 landed
-
Fix test failures when language environment is not UTF-8.
- e2a235767180 17.0 landed
-
Add unicode_strtitle() for Unicode Default Case Conversion.
- 46e5441fa536 17.0 landed
-
Use version for builtin collations.
- 46a44dc37203 17.0 landed
-
Fix convert_case(), introduced in 5c40364dd6.
- 503c0ad976f5 17.0 landed
-
Inline basic UTF-8 functions.
- 9acae56ce0b0 17.0 landed
-
Support C.UTF-8 locale in the new builtin collation provider.
- f69319f2f1fb 17.0 landed
-
Fix another warning, introduced by 846311051e.
- 60769c62dc85 17.0 landed
-
Address more review comments on commit 2d819a08a1.
- 846311051e8f 17.0 landed
-
Fix unreachable code warning from commit 2d819a08a1.
- 61f352ece9e7 17.0 landed
-
Introduce "builtin" collation provider.
- 2d819a08a1cb 17.0 landed
-
Catalog changes preparing for builtin collation provider.
- f696c0cd5f29 17.0 landed
-
Unicode case mapping tables and functions.
- 5c40364dd6d9 17.0 landed
-
Add Unicode property tables.
- ad49994538c5 17.0 landed
-
Documentation update for Standard Collations.
- 875e46a0a246 17.0 landed
-
Cleanup for unicode-update build target and test.
- cf64d4e99f64 17.0 landed
-
Shrink Unicode category table.
- 719b342d36ce 17.0 landed
-
Make some error strings more generic
- 36a14afc0760 17.0 cited
-
pg_upgrade: copy locale and encoding information to new cluster.
- 9637badd9f92 16.0 cited
-
Update Unicode data to Unicode 15.0.0
- 1091b48cd761 16.0 cited
-
Create a new type category for "internal use" types.
- 07eee5a0dc64 15.0 cited