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

Reply via email to