MIME-Version: 1.0
References: <92f32dd57c4d11777c885d211655aceb799d6ecd.camel@j-davis.com>
In-Reply-To: <92f32dd57c4d11777c885d211655aceb799d6ecd.camel@j-davis.com>
From: Gurjeet Singh <gurjeet@singh.im>
Date: Sat, 17 Jun 2023 09:09:02 -0700
Message-ID: <CABwTF4WBTHfx7=s+c4HNeEZO0d7Mq7V8Q4qPC2DR-TTrq7JfrA@mail.gmail.com>
Subject: Re: [17] CREATE COLLATION default provider
To: Jeff Davis <pgsql@j-davis.com>
Cc: pgsql-hackers@postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CABwTF4WBTHfx7%3Ds%2Bc4HNeEZO0d7Mq7V8Q4qPC2DR-TTrq7JfrA%40mail.gmail.com>
Precedence: bulk

On Wed, Jun 14, 2023 at 9:48=E2=80=AFPM Jeff Davis <pgsql@j-davis.com> wrot=
e:
>
> Currently, CREATE COLLATION always defaults the provider to libc.
>
> The attached patch causes it to default to libc if LC_COLLATE/LC_CTYPE
> are specified, otherwise default to the current database default
> collation's provider.

+            if (lccollateEl || lcctypeEl)
+                collprovider =3D COLLPROVIDER_LIBC;
+            else
+                collprovider =3D default_locale.provider;

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.

Otherwise the patch looks good.

> v11-0001-CREATE-COLLATION-default-provider.patch

I believe v11 is a typo, and you really meant v1.

Best regards,
Gurjeet
http://Gurje.et