Message-ID: <c7d6df46ffbfb1af38b18d934ac3a81ffccb7fc8.camel@j-davis.com>
Subject: Re: Built-in CTYPE provider
From: Jeff Davis <pgsql@j-davis.com>
To: Jeremy Schneider <schneider@ardentperf.com>, Daniel Verite
	 <daniel@manitou-mail.org>
Cc: Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@postgresql.org
Date: Tue, 09 Jan 2024 14:31:59 -0800
In-Reply-To: <2b98e5d9-6c51-41cf-8017-88a6a6a129bc@ardentperf.com>
References: <dd9261f4-7a98-4565-93ec-336c1c110d90@manitou-mail.org>
	 <6b1370d5eaba5e8c42f54c05f7bc2b8e27b8db12.camel@j-davis.com>
	 <804eb67b37f41d3afeb2b6469cbe8bfa79c562cc.camel@j-davis.com>
	 <2b98e5d9-6c51-41cf-8017-88a6a6a129bc@ardentperf.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.4-0ubuntu2 
MIME-Version: 1.0
Archived-At: <https://www.postgresql.org/message-id/c7d6df46ffbfb1af38b18d934ac3a81ffccb7fc8.camel%40j-davis.com>
Precedence: bulk

On Tue, 2024-01-09 at 14:17 -0800, Jeremy Schneider wrote:
> I think we missed something in psql, pretty sure I applied all the
> patches but I see this error:
>=20
> =3D# \l
> ERROR:=C2=A0 42703: column d.datlocale does not exist
> LINE 8:=C2=A0=C2=A0 d.datlocale as "Locale",
>=20

Thank you. I'll fix this in the next patch set.

> This is interesting. Jeff your original email didn't explicitly show
> any
> other initcap() results, but on Ubuntu 22.04 (glibc 2.35) I see
> different results:
>=20
> =3D# SELECT initcap('axxE =C3=A1xx=C3=89 =C7=84xx=C7=84 =C7=85xxx =C7=86x=
xx');
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 initcap
> --------------------------
> =C2=A0Axxe =C3=81xx=C3=A9 =C7=84xx=C7=86 =C7=84xxx =C7=84xxx
>=20
> =3D# SELECT initcap('axxE =C3=A1xx=C3=89 =C7=84xx=C7=84 =C7=85xxx =C7=86x=
xx' COLLATE C_UTF8);
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 initcap
> --------------------------
> =C2=A0Axxe =C3=81xx=C3=A9 =C7=85xx=C7=86 =C7=85xxx =C7=85xxx

The reason for this difference is because libc doesn't support
titlecase. In the next patch set, I'll not use titlecase (only
uppercase/lowercase even for initcap()), and then it will match libc
100%.

> The COLLATE sql syntax feels awkward to me. In this example, we're
> just
> using it to attach locale info to the string, and there's not
> actually
> any collation involved here. Not sure if COLLATE comes from the
> standard, and even if it does I'm not sure whether the standard had
> upper/lowercase in mind.

The standard doesn't use the COLLATE clause for case mapping, but also
doesn't offer any other mechanism to, e.g., get case mapping according
to the "tr_TR" locale.

I think what Postgres does here, re-purposing the COLLATE clause to
allow tailoring of case mapping, is imperfect but reasonable. My
proposal doesn't change that.

Regards,
	Jeff Davis