Search Postgresql Archives

Re: Mixing different LC_COLLATE and database encodings

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Bill Moseley wrote:
> What's a bad idea?  Having a lc_collate on the cluster that doesn't
> support the encodings in the databases?

Exactly

> Again, not sure what "it" is, but I do find it confusing when the
> cluster can have only one lc_collate, but the databases on that
> cluster can have more than one encoding.

It is confusing, so don't do it.

> That's why I was asking 
> how postgresql handles (possibly) different encodings.

It doesn't.

> Are you saying that if a database is encoded as utf8 then the cluster
> should be initiated with something like en_US.utf8?  And then all
> databaes on that cluster should be encoded the same?

Yes

> I thought the locale defines the order of the characters, but not the
> encoding of those characters.

In theory, they are independent concepts.  But in practice, the C 
library gets a bunch bytes from the application (in this case, the 
PostgreSQL server) and is asked to sort them.  So it needs to know what 
these bytes are supposed to mean.  By design of the POSIX locale 
facilities, the C library is told that by way of the locale.  It would 
be much simpler for everyone if there was a function strcmp(string1, 
string2, collation, encoding), but there isn't.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux