2010/11/16 Peter Eisentraut <pete...@gmx.net>: > On tis, 2010-11-16 at 20:59 +0100, Pavel Stehule wrote: >> 2010/11/16 Peter Eisentraut <pete...@gmx.net>: >> > On tis, 2010-11-16 at 20:00 +0100, Pavel Stehule wrote: >> >> yes - my first question is: Why we need to specify encoding, when only >> >> one encoding is supported? I can't to use a cs_CZ.iso88592 when my db >> >> use a UTF8 - btw there is wrong message: >> >> >> >> yyy=# select * from jmena order by jmeno collate "cs_CZ.iso88592"; >> >> ERROR: collation "cs_CZ.iso88592" for current database encoding >> >> "UTF8" does not exist >> >> LINE 1: select * from jmena order by jmeno collate "cs_CZ.iso88592"; >> >> ^ >> > >> > Sorry, is there some mistake in that message? >> > >> >> it is unclean - I expect some like "cannot to use collation >> cs_CZ.iso88502, because your database use a utf8 encoding". > > No, the namespace for collations is per encoding. (This is per SQL > standard.) So you *could* have a collation called "cs_CZ.iso88502" for > the UTF8 encoding. > >> I have not a problem with size. Just I think, current behave isn't >> practical. When database encoding is utf8, then I except, so "cs_CZ" >> or "czech" will be for utf8. I understand, so template0 must have a >> all locales, and I understand why current behave is, but it is very >> user unfriendly. Actually, only old application in CR uses latin2, >> almost all uses a utf, but now latin2 is preferred. This is bad and >> should be solved. > > Again, we can only look at the locale names that the operating system > gives us. Mapping that to the names you expect is an AI problem. If > you have a solution, please share it. >
ok, then we should to define this alias manually some like - CREATE COLLATE "czech" FOR LOCALE "cs_CZ.UTF8" or some similar. Without this, the application or stored procedures can be non portable between UNIX and WIN. Peter, now initdb check relation between encoding and locale - and this check is portable. Can we use this code? Pavel > > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
