ITAGAKI Takahiro <[EMAIL PROTECTED]> writes: > Your patch looks useful to prevent mismatch of encoding and locale on Windows, > but I found there is a limitation that user will not able to specify locale. > I added an alternative of nl_langinfo(CODESET) for Win32.
Applied with small correction --- it looked like you'd put in the wrong PG_ENC code for GBK and BIG5. Not terribly important since we'd reject them anyway, but we might as well reject with the correct error message. This still leaves the policy decision of whether we want to have initdb assume "-E UTF8 --no-locale" if it sees the current locale has an unusable encoding. I'm not really happy with that idea because it would disable localization of messages. I think what we want, at least on Windows, is to switch to the "corresponding" locale that uses UTF8. Is there a simple way to do that? Or at least some simple recipe we can put into the documentation? "If you get this sort of error, use this --locale setting..." regards, tom lane ---------------------------(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