Re: Order changes in PG16 since ICU introduction
От | Peter Eisentraut |
---|---|
Тема | Re: Order changes in PG16 since ICU introduction |
Дата | |
Msg-id | 696054d1-bc88-b6ab-129a-18b8bce6a6f0@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Order changes in PG16 since ICU introduction (Peter Eisentraut <peter.eisentraut@enterprisedb.com>) |
Ответы |
Re: Order changes in PG16 since ICU introduction
|
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: