[Peter Eisentraut <peter.eisentraut@enterprisedb.com>]

On 21.04.23 19:14, Peter Eisentraut wrote:
> On 21.04.23 19:09, Sandro Santilli wrote:
>> On Fri, Apr 21, 2023 at 11:48:51AM -0400, Tom Lane wrote:
>>> "Regina Obe" <lr@pcorp.us> writes:
>>>
>>>> https://trac.osgeo.org/postgis/ticket/5375
>>>
>>> If they actually are using locale C, I would say this is a bug.
>>> That should designate memcmp sorting and nothing else.
>>
>> Sounds like a bug to me. This is happening with a PostgreSQL cluster
>> created and served by a build of commit c04c6c5d6f :
>>
>>    =# select version();
>>    PostgreSQL 16devel on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 
>> 11.3.0-1ubuntu1~22.04) 11.3.0, 64-bit
>>    =# show lc_collate;
>>    C
>>    =# select '+' < '-';
>>    f
> 
> If the database is created with locale provider ICU, then lc_collate 
> does not apply here, so the result might be correct (depending on what 
> locale you have set).

The GUC settings lc_collate and lc_ctype are from a time when those 
locale settings were cluster-global.  When we made those locale settings 
per-database (PG 8.4), we kept them as read-only.  As of PG 15, you can 
use ICU as the per-database locale provider, so what is being attempted 
in the above example is already meaningless before PG 16, since you need 
to look into pg_database to find out what is really happening.

I think we should just remove the GUC parameters lc_collate and lc_ctype.