Re: ICU for global collation - Mailing list pgsql-hackers

From Daniel Verite
Subject Re: ICU for global collation
Date
Msg-id 374f8048-9d87-462c-a8aa-d02ffca6525f@manitou-mail.org
Whole thread Raw
In response to Re: ICU for global collation  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: ICU for global collation  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
    Peter Eisentraut wrote:

> 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.

Even if the FTS code is improved in that matter, any extension code
with libc functions depending on LC_CTYPE is still going to be
potentially problematic. In particular when it happens to be set
to a different encoding than the database.

Couldn't we simply invent per-database GUC options, as in
ALTER DATABASE myicudb SET libc_lc_ctype TO 'value';
ALTER DATABASE myicudb SET libc_lc_collate TO 'value';

where libc_lc_ctype/libc_lc_collate would specifically set
the values in the LC_CTYPE and LC_COLLATE environment vars
of any backend serving the corresponding database"?


Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite



pgsql-hackers by date:

Previous
From: Marko Tiikkaja
Date:
Subject: Re: [PATCH] Implement INSERT SET syntax
Next
From: Peter Geoghegan
Date:
Subject: Re: Remove configure --disable-float4-byval and --disable-float8-byval