While looking through old emails, I bumped into this:


To recap, setlocale() on Windows is broken for locale names that contain dots or apostrophes in the country name. That includes "Hong Kong S.A.R.", "Macau S.A.R.", and "U.A.E." and "People's Republic of China".

In April, I put in a hack to initdb to map those problematic names to aliases that don't contain dots:

People's Republic of China -> China
Hong Kong S.A.R. -> HKG
U.A.E. -> ARE
Macau S.A.R. -> ZHM

However, Hiroshi pointed out in the thread linked above that that doesn't completely solve the problem. If you set locale to "HKG", for example, setlocale(LC_ALL, NULL) still returns the full name, "Hong Kong S.A.R.", and if you feed that back to setlocale() it fails. In particular, check_locale() uses "saved = setlocale(LC_XXX, NULL)" to get the current value, and tries to restore it later with "setlocale(LC_XXX, saved)".

At first, I thought I should revert my hack in initdb, since it's not fully solving the problem anyway. But it doesn't really help - you run into the same issue if you set locale to one of those aliases manually. And that's exactly what users will have to do if we don't map those locales automatically.

Microsoft should fix their bug. I don't have much faith in that happening, however. So, I think we should move the mapping from initdb to somewhere in src/port, so that the mapping is done every time setlocale() is called. That would fix the problem with check_locale(): even though "setlocale(LC_XXX, NULL)" returns a value that won't work, the setlocale() call to restore it would map it to an alias that does work again.

In addition to that, I think we should check the return value of setlocale() in check_locale(), and throw a warning if restoring the old locale fails. The session's locale will still be screwed, but at least you'll know if it happens.

I'll go write a patch for that.

  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to