From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Can ICU be used for a database's default sort order? |
Date: | 2017-06-23 22:54:36 |
Message-ID: | CAH2-Wzm51+u5nuqCB=cQ8_JaWA8=2t=AFKt7Uf3Ye71tXUof0w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jun 23, 2017 at 11:32 AM, Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> It's something I hope to address soon.
I hope you do. I think that we'd realize significant benefits by
having ICU become the defacto standard collation provider, that most
users get without even realizing it. As things stand, you have to make
a point of specifying an ICU collation as your per-column collation
within every CREATE TABLE. That's a significant barrier to adoption.
> 1) Associate by name only. That is, you can create a database with any
> COLLATION "foo" that you want, and it's only checked when you first
> connect to or do anything in the database.
>
> 2) Create shared collations. Then we'd need a way to manage having a
> mix of shared and non-shared collations around.
>
> There are significant pros and cons to all of these ideas. Some people
> I talked to appeared to prefer the shared collations approach.
I strongly prefer the second approach. The only downside that occurs
to me is that that approach requires more code. Is there something
that I've missed?
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-06-23 23:09:52 | Re: pg_terminate_backend can terminate background workers and autovacuum launchers |
Previous Message | Tom Lane | 2017-06-23 22:20:20 | Re: initdb initalization failure for collation "ja_JP" |