Re: Issues with german locale on CentOS 5,6,7

From: "Daniel Verite" <daniel(at)manitou-mail(dot)org>
To: "Thomas Kellerer" <spam_eater(at)gmx(dot)net>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Issues with german locale on CentOS 5,6,7
Date: 2015-10-08 12:35:11
Message-ID: 8b22d3e2-2d09-4ff0-8c95-bd67e011ea13@mm
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Thomas Kellerer wrote:

> I always thought that this is a major shortcoming (if not a bug) in Postgres
> that the collation support is left to the OS.
>
> Because it essentially means that that exactly the same query with exactly
> the same data might return a different result if run on different OS

Could an extension help with this?

CREATE EXTENSION pg_locales;

The extension would provide its own strcoll/strxfrm/etc. and a set
of locale definitions, presumably slurped from Linux or BSD.

It would probably be preloaded in postgresql.conf:
shared_preload_libraries = pg_locales

A collation would be created with
SELECT create_pg_collation(name,locale,lc_collate,lc_ctype);
which would be a kind of CREATE COLLATION but relying on the
extension code/data rather than the libc.

Then tables and columns could be set to use that collation, and the
core postgres code should divert the corresponding string comparisons
to the extension functions.

Benefits:
- being insulated from unexpected OS changes.
- portability across OS, assuming that the extension would be itself
portable.
- the core postgres would not be responsible of maintaining these locales.

Would something like that make sense?

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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2015-10-08 13:30:44 Re: postgres standby won't start
Previous Message Vick Khera 2015-10-08 12:12:20 Re: Best practices for aggregate table design