Re: [HACKERS] Can ICU be used for a database's default sort order?
От | Peter Eisentraut |
---|---|
Тема | Re: [HACKERS] Can ICU be used for a database's default sort order? |
Дата | |
Msg-id | f689322a-4fc5-10cc-4a60-81f1ff0166c9@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Can ICU be used for a database's default sort order? (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: [HACKERS] Can ICU be used for a database's default sort order?
Re: [HACKERS] Can ICU be used for a database's default sort order? |
Список | pgsql-hackers |
On 6/22/17 23:10, Peter Geoghegan wrote: > On Thu, Jun 22, 2017 at 7:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Is there some way I'm missing, or is this just a not-done-yet feature? > > It's a not-done-yet feature. It's something I hope to address soon. The main definitional challenge is how to associate a pg_database entry with a collation. What we currently effectively do is duplicate the fields of pg_collation in pg_database. But I imagine over time we'll add more properties in pg_collation, along with additional ALTER COLLATION commands etc., so duplicating all of that would be a significant amount of code complication and result in a puzzling user interface. Ideally, I'd like to see CREATE DATABASE ... COLLATION "foo". But the problem is of course that collations are per-database objects. Possible solutions: 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. Other ideas? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: