Re: [17] CREATE COLLATION default provider

From: Gurjeet Singh <gurjeet(at)singh(dot)im>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [17] CREATE COLLATION default provider
Date: 2023-07-07 17:44:53
Message-ID: CABwTF4WxOJ7gBMy-oM2xqCMPQSs63tQPokzB3AAouHbv-=z2Lg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jul 7, 2023 at 9:33 AM Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
>
> 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.

Sorry about the noise, I was consulting current/v15 docs online. Now
that v16 docs are online, I can see that the option in fact says this
is the case only if libc is the provider.

(note to self: for reviewing patches to master, consult devel docs [1] online)

[1]: https://www.postgresql.org/docs/devel/

Best regards,
Gurjeet
http://Gurje.et

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Akshat Jaimini 2023-07-07 18:12:48 Re: Add more sanity checks around callers of changeDependencyFor()
Previous Message Daniel Verite 2023-07-07 17:42:57 Re: psql's FETCH_COUNT (cursor) is not being respected for CTEs