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

From Florian Pflug
Subject Re: Changing the concept of a DATABASE
Date
Msg-id 09ABCC6E-0306-472B-939E-C6A98A4EC102@phlo.org
Whole thread Raw
In response to Re: Changing the concept of a DATABASE  (Susanne Ebrecht <susanne@2ndquadrant.com>)
List pgsql-hackers
On May22, 2012, at 18:00 , Susanne Ebrecht wrote:
> 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.

Still, the whole reason that the encoding is a per-database property is
that we don't tag each string with its encoding. To support cross-database
queries, we'd have to do that, and could then just as well make the encoding
a per-column property, or at least so I think.

> 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.

You could always write at pl/pgsql function which iterates over all columns
of type text or varchar within a schema and sets the desired collation, but

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

yeah, that'd definitely be nice.

best regards,
Florian Pflug



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Readme of Buffer Management seems to have wrong sentence
Next
From: chinnaobi
Date:
Subject: Re: hot standby PSQL 9.1 Windows 2008 Servers