On 04.06.2013 09:39, Martin Schäfer wrote:
Can't really blame Windows on that. On Windows, we don't require that the
encoding and LC_CTYPE's charset match. The OP used UTF-8 encoding in the
server, but LC_CTYPE="English_United Kingdom.1252", ie. LC_CTYPE implies
WIN1252 encoding. We allow that and it generally works on Windows
because in varstr_cmp, we use MultiByteToWideChar() followed by
wcscoll_l(), which doesn't care about the charset implied by LC_CTYPE.
But for isupper(), it matters.
Does this mean that the UTF-8 messing up would disappear if the database were
using a different locale for LC_CTYPE? If so, which locale should I use?
This would be useful for a temporary workaround.
Maybe, not sure. The logical thing to do would be to set LC_CTYPE to
"English_United Kingdom.65001", which tell Windows to expect UTF-8
charset. However, old discussions on this subject suggest that Windows
won't accept that:
http://www.postgresql.org/message-id/20071015090954.gd4...@svr2.hagander.net
It's still worth a try, I think. Things might've changed since then. If
that doesn't work, you could also try some other random codepages as a
workaround. If you're lucky, one of them might work better, even though
it would still be the wrong codepage for UTF-8.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
