Re: [HACKERS] Can ICU be used for a database's default sort order?

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: [HACKERS] Can ICU be used for a database's default sort order?
Дата
Msg-id 4388e40f-847d-6d59-b782-0451b8fdefe9@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Can ICU be used for a database's default sort order?  (Andrey Borodin <x4mmm@yandex-team.ru>)
Ответы Re: [HACKERS] Can ICU be used for a database's default sort order?  ("Daniel Verite" <daniel@manitou-mail.org>)
Re: [HACKERS] Can ICU be used for a database's default sort order?  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
On 02/12/2018 15:40, Andrey Borodin wrote:
> Daniel have raised important interface question in his review. Using libc-style locale in lc_collate is not a perfect
choicefor many ICU-only collations.
 
> I'd work on patch if I knew how to improve the interface, but I need input from community: how this interface should
looklike.
 

Figuring out the interface is the hard part.  Several options have been
discussed in this thread and earlier threads.

My current thinking is that we should add a datcollprovider column to
pg_database, and then store the ICU locale name in datcollate.  So
mirror the columns of pg_collation in pg_database.

Another issue is that we'd need to carefully divide up the role of the
"default" collation and the "default" provider.  The default collation
is the collation defined for the database, the default provider means to
use the libc non-locale_t enabled API functions.  Right now these are
always the same, but if the database-global locale is ICU, then the
default collation would use the ICU provider.

My recently posted patch "Reorganize collation lookup time and place" is
meant to help reorganize the APIs to make this simpler.  It doesn't have
all the answers yet, but I think it's a step in this direction.

If we have well-designed answers to these questions, I'd imagine that
the actual feature patch would be quite small.  I was very surprised to
see how large this patch is and how much code is moves around without
much explanation.  I don't think it's worth reviewing this patch any
further.  It needs several steps back and some fundamental design and
refactoring work.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Why not represent "never vacuumed" accurately wrt pg_class.relpages?
Следующее
От: Sergei Kornilov
Дата:
Сообщение: Re: allow online change primary_conninfo