Re: tiny step toward threading: reduce dependence on setlocale()

On 07.08.24 22:44, Peter Eisentraut wrote:
> (Now that I look at it, pg_tolower() has some short-circuiting for ASCII
> letters, so it would not handle Turkish-i correctly if that had been the
> global locale.  By removing the use of pg_tolower(), we fix that issue
> in passing.)

It occurred to me that this issue also surfaces in a more prominent
place. These arguably-wrong pg_tolower() and pg_toupper() calls were
also used by the normal SQL lower() and upper() functions before commit
e9931bfb751 if you used a single byte encoding.

For example, in PG17, multi-byte encoding:

initdb --locale=tr_TR.utf8

select upper('hij'); --> HİJ

PG17, single-byte encoding:

initdb --locale=tr_TR # uses LATIN5

select upper('hij'); --> HIJ

With current master, after commit e9931bfb751, you get the first result
in both cases.

So this could break indexes across pg_upgrade in such configurations.