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

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
Cc: daniel(at)manitou-mail(dot)org, Michael Paquier <michael(at)paquier(dot)xyz>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, pg(at)bowt(dot)ie, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Can ICU be used for a database's default sort order?
Date: 2018-12-11 08:22:48
Message-ID: 4388e40f-847d-6d59-b782-0451b8fdefe9@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 choice for 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 look like.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sergei Kornilov 2018-12-11 08:59:08 Re: allow online change primary_conninfo
Previous Message Andres Freund 2018-12-11 07:20:05 Why not represent "never vacuumed" accurately wrt pg_class.relpages?