Subject: Re: ICU for global collation
To: Daniel Verite <daniel@manitou-mail.org>
References: <5d807706-60a2-4e56-bc59-eef9e7deb138@manitou-mail.org>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Organization: 2ndQuadrant
Message-ID: <23ddce07-94a0-581a-eadc-16323e5d261a@2ndquadrant.com>
Date: Thu, 31 Oct 2019 08:22:44 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0)
 Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <5d807706-60a2-4e56-bc59-eef9e7deb138@manitou-mail.org>
Content-Type: text/plain; charset=iso-8859-15; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 2019-09-17 15:08, Daniel Verite wrote:
> When trying databases defined with ICU locales, I see that backends
> that serve such databases seem to have their LC_CTYPE inherited from
> the environment (as opposed to a per-database fixed value).

> fr-utf8=# select to_tsvector('été');
> ERROR:	invalid multibyte character for locale
> HINT:  The server's LC_CTYPE locale is probably incompatible with the
> database encoding.

I looked into this problem.  The way to address this would be adding 
proper collation support to the text search subsystem.  See the TODO 
markers in src/backend/tsearch/ts_locale.c for starting points.  These 
APIs spread out to a lot of places, so it will take some time to finish. 
  In the meantime, I'm pausing this thread and will set the CF entry as RwF.

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