From: | "Daniel Verite" <daniel(at)manitou-mail(dot)org> |
---|---|
To: | "Peter Eisentraut" <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ICU for global collation |
Date: | 2019-11-01 18:18:13 |
Message-ID: | 374f8048-9d87-462c-a8aa-d02ffca6525f@manitou-mail.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2019-11-01 19:15:06 | Re: Remove configure --disable-float4-byval and --disable-float8-byval |
Previous Message | Marko Tiikkaja | 2019-11-01 18:00:47 | Re: [PATCH] Implement INSERT SET syntax |