From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Gurjeet Singh <gurjeet(at)singh(dot)im> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [17] CREATE COLLATION default provider |
Date: | 2023-07-07 16:32:58 |
Message-ID: | 847808fd892c91835f880194f97eefcd62bbe36e.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, 2023-06-17 at 09:09 -0700, Gurjeet Singh wrote:
> The docs for the CREATE COLLATION option 'locale' say: "This is a
> shortcut for setting LC_COLLATE and LC_CTYPE at once."
>
> So it's not intuitive why the check does not include a test for the
> presence of 'localeEl', as well? If we consider the presence of
> LC_COLLATE _or_ LC_CTYPE options to be a determining factor for some
> decision, then the presence of LOCALE option should also lead to the
> same outcome.
>
The docs say: "If provider is libc, this is a shortcut...". The point
is that LC_COLLATE and LC_CTYPE act as a signal that what the user
really wants is a libc collation. LOCALE works for either, so we need a
default.
That being said, I'm now having second thoughts about where that
default should come from. While getting the default from datlocprovider
is convenient, I'm not sure that the datlocprovider provides a good
signal. A lot of users will have datlocprovider=c and datcollate=C,
which really means they want the built-in memcmp behavior, and to me
that doesn't signal that they want CREATE COLLATION to use libc for a
non-C locale.
A GUC might be a better default, and we could have CREATE COLLATION
default to ICU if the server is built with ICU and if PROVIDER,
LC_COLLATE and LC_CTYPE are unspecified.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Matthias van de Meent | 2023-07-07 16:34:09 | Re: HOT readme missing documentation on summarizing index handling |
Previous Message | Jeff Davis | 2023-07-07 16:22:22 | Re: pgsql: Fix search_path to a safe value during maintenance operations. |