From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [17] collation provider "builtin" |
Date: | 2023-06-16 14:01:26 |
Message-ID: | 96664b2e-4af8-4236-77a7-a1ee590a0617@eisentraut.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 15.06.23 00:55, Jeff Davis wrote:
> The locale "C" (and equivalently, "POSIX") is not really a libc locale;
> it's implemented internally with memcmp for collation and
> pg_ascii_tolower, etc., for ctype.
>
> The attached patch implements a new collation provider, "builtin",
> which only supports "C" and "POSIX". It does not change the initdb
> default provider, so it must be requested explicitly. The user will be
> guaranteed that collations with provider "builtin" will never change
> semantics; therefore they need no version and indexes are not at risk
> of corruption. See previous discussion[1].
What happens if after this patch you continue to specify provider=libc
and locale=C? Do you then get the "slow" path?
Should there be some logic in pg_dump to change the provider if locale=C?
What is the transition plan?
From | Date | Subject | |
---|---|---|---|
Next Message | Melih Mutlu | 2023-06-16 14:03:14 | Parent/child context relation in pg_get_backend_memory_contexts() |
Previous Message | Peter Eisentraut | 2023-06-16 13:45:06 | Re: [DOC] Update ALTER SUBSCRIPTION documentation v3 |