Re: Changing the concept of a DATABASE - Mailing list pgsql-hackers

From Susanne Ebrecht
Subject Re: Changing the concept of a DATABASE
Date
Msg-id 4FBBB824.9090000@2ndquadrant.com
Whole thread Raw
In response to Re: Changing the concept of a DATABASE  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Changing the concept of a DATABASE
Re: Changing the concept of a DATABASE
Re: Changing the concept of a DATABASE
List pgsql-hackers
Am 22.05.2012 17:42, schrieb Tom Lane:
> Encoding yes, but since 9.1 we have pretty fine-grained control of
> collation.  So I think this argument is a lot weaker than it used
> to be.  It would only really apply if you have one of the corner
> cases where utf8 doesn't work for you.

Yeah it got better - but it isn't perfect yet.

Maybe I am blind or 9.1 documentation has a bug - but according to the
documentation you can't change default collation per schema or per table.
You can set collation per column - but do you really want to set 
collation for
every single column of every single supported language in your 200+ tables
web tool?

That is a huge effort and a huge maintenance effort.

Usually you want to set the collation once per language schema. E.g. schema
russian gets Russian collation and schema British gets British collation 
and so on.

CREATE SCHEMA foo LC_COLLATE bar isn't supported so you went up a level and
do it by creating a database.

I would like to get default collation per schema / table in 9.2 or 9.3 
but that is my personal
wish,

Susanne


-- 
Dipl. Inf. Susanne Ebrecht - 2ndQuadrant
PostgreSQL Development, 24x7 Support, Training and Services
www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Readme of Buffer Management seems to have wrong sentence
Next
From: Thom Brown
Date:
Subject: Re: Per-Database Roles