On Mon, Oct 22, 2007 at 10:55:14AM -0400, Tom Lane wrote: > Magnus Hagander <[EMAIL PROTECTED]> writes: > > As I chatted with Dave about - wnat encoding? We pull that value cluster > > wide, but the encoding is per-database. You could have one UTF8 and one > > WIN1252 database... > > Will chklocale.c actually allow that? Should it? We've spent a lot of > time zeroed in on initdb's behavior, but the other piece of the puzzle > is which DB encodings should CREATE DATABASE allow afterwards. It > sounds to me that Windows may be more flexible than the standard Unix > locale support on this point, but I'm not sure how much more flexible.
Yes, if I pick the proper locale, it does work. FOr example, I can properly initdb in UTF8 and then create a WIN1252 database. > There's also the question of how we make sure that strings returned > by the OS (eg strerror) are in the DB's encoding. I think that the > Unix side is not fully up to speed on that either --- we don't try > to prevent you from setting, eg, LC_MESSAGES = foo.utf8 when LC_CTYPE > and the DB encoding are iso88591. I've thought about trying to enforce > that the encoding-suffix-if-any is the same as LC_CTYPE's for all the LC_ > values, but I'm not sure whether that approach is sane for Windows. That's a potential problem - I assume you'll have the same problem as on Unix if you say your db is in UTF8 buy your messages are in LATIN1. //Magnus ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match