From: | "Daniel Verite" <daniel(at)manitou-mail(dot)org> |
---|---|
To: | "Dirk Mika" <Dirk(dot)Mika(at)mikatiming(dot)de> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Set COLLATE on a session level |
Date: | 2020-12-05 14:31:05 |
Message-ID: | 76c8ddd8-f52d-4020-a767-06ce1db11d0f@manitou-mail.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Dirk Mika wrote:
> My sentence was more along the lines that I cannot imagine that I am the
> first to have this problem and that there should therefore be an easier
> solution. But apparently the topic is not so relevant in general. 😉
I'm not sure, but it's plausible that with Oracle, the real use case
for ALTER SESSION SET nls_sort=... is to avoid a binary sort.
There's a clear difference between binary sort and all linguistic
sorts, but few differences across linguistic sorts.
These differences tend to be subtle and ignorable by end users.
Also when storing texts from multiple languages in a database, a
session parameter picking a specific region/language will be right
for only a portion of your texts anyway.
With PostgreSQL, if the database is in UTF8 encoding with a default
collation like "en_US", or more generally language_COUNTRY,
the default sorts are already performed with the Unicode collation
algorithm (by the operating system libc) with reasonable generic
sort rules. Possibly most users would not even notice the
differences that would occur between collations if you used
per-language collations according to users preferences.
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: https://www.manitou-mail.org
Twitter: @DanielVerite
From | Date | Subject | |
---|---|---|---|
Next Message | Karsten Hilbert | 2020-12-05 14:54:49 | Aw: Re: Set COLLATE on a session level |
Previous Message | Karsten Hilbert | 2020-12-05 14:18:29 | Aw: Re: Set COLLATE on a session level |